M-MS2  CSS 

UNCLASSIFIED 


SPECIFICATION  TECHNOLOOV  OUIDELINESCU)  NEIHG  AEAOSPACE 
CO  KENT  HA  0  A  AODLEHAN  ET  AL.  AUO  OS  RADC-TK-OS-120 
F30S02-S4-C-0073 

F/0  9/2 


tn 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BU«CAU  Of  STANDARDS  -  «96J  *  4 


I 

I 


AD-A162  655 


RADC-TR-85-128 
Final  Technical  Report 
August  1985 


to 


SPECIFICATION  TECHNOLOGY  GUIDELINES 


Boeing  Aerospace  Company 


David  R.  Addleman,  Margaret  J.  Davis  and  R.  Edward  Presson 


APPROVED  FOR  POBLIC  RELEASE;  DISTRIBUTION  UNLINIITED 


8 

UJ 


DTIC 

ELECTE 
DEC  2  0  1985 


ROME  AIR  DEVELOPMENT  CENTER 
Air  Force  Systems  Command 
Griffiss  Air  Force  Base,  NY  13441-5700 


85  12  20  003  , 


Tikis  rqiort  has  been  reviewed  by  the  RASC  Public  Affairs  Office  (PA) 
is  riAesseble  to  the  National  Technical  Information  Service  (NTIS) .  At 
KCXS  it  will  be  releasable  to  the  general  public.  Including  foreign  nations. 

NgDC.Tg-85-128  has  been  reviewed  and  Is  approved  for  publication. 


APPROVED: 

WILLIAM  E.  RZEPKA 
ProJ  ect  Engineer 


APPROVED: 

RAYMOND  P.  URTZ,  Jr. 
Technical  Director 
Command  and  Control  Division 


FOR  THE  COMMANDER: 


RICHARD  W,  POULIOT 
Plans  Office 


If  your  address  has  changed  or  if  you  wish  to  be  removed  from  the  RADC 
mailing  list,  or  if  the  addressee  is  no  longer  employed  by  your  organization, 
please  notify  RADC  (COEE)  Griffiss  AFB  NY  13441-5700.  This  will  assist  us  in 
maintaining  a  current  mailing  list. 


Do  not  return  copies  of  this  report  unless  contractual  obligations  or  notices 
on  a  specific  document  requires  that  it  be  returned. 


'INCLASSIFIED 


SECURITY  CLASSIFICATION  OF  THIS  PAGE 


1a  REPORT  SECURITY  CLASSIFICATION 


REPORT  DOCUMENTATION  PAGE 


ia  SECURITY  CLASSIFICATION  AUTHORITY 

N/A 


2b  DECLASSIFICATION /DOWNGRADING  SCHEDULE 

N/A  _ 


4  PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 

N/A 


6a  NAME  OF  PERFORMING  ORGANIZATION 
Boeing  Aerospace  Company 


6c.  ADDRESS  (Cfy,  State,  and  ZIP  Code) 
Seattle  WA  98124 


6h  OFFICE  SYMBOL 
(If  applicahle) 


lb  RESTRICTIVE  MARKINGS 

N/A 

3  DISTRIBUTION/ A,/ AILABlLiTY  OF  REPORT 

Approved  for  public  rele..:je; 

distribution 

unlimited 

Is  MONITORING  ORGANIZATION  REPORT  NUMBER(S) 

RADC-TR-85-128 

7a  NAME  OF  MONITORING  ORGANIZATION 

Rome  Air  Development  Center 

(COEE) 

7b  ADDRESS  (City,  State,  and  ZIP  Code) 

Grifflss  AFB  NY  13441-5700 


8a.  NAME  OF  FUNDING /SPONSORING 
ORGANIZATION 

Rome  Air  Development  Center 


8c.  ADDRESS  (City,  State,  and  ZIP  Code) 

Grifflss  AFB  NY  13441-5700 


11  TITLE  (Include  Security  Classification) 
SPECIFICATION  TECHNOLOGY  GUIDELINES 


8b  OFFICE  SYMBOL  9  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 
(If  applicable) 

COEE  F30602-84-C-0073 


10  SOURCE  Of  Funding  numbers 


PROGRAM 
ELEMENT  NO 

62702F 


PROJECT 

TASK 

NO 

NO 

5581 

22 

WORK  UNIT 
ACCESSION  NO 


12  PERSONAL  AUTMOR(S) 

David  R,  Addleman,  Margaret  J.  Davis,  Edward  P.  Presson 


13a  TYPE  OF  REPORT  1 3b  TIME  COVERED  14  DATE  OF  REPORT  (YeaM'vlonth,  Day)  IS  PAGE  COUNT 

Final  from  2Mar84  to  lMar85  August  1985 


16  SUPPLEMENTARY  NOTATION 
N/A 


COSATI  COOES 


SUB-GROUP 


18  SUBJECT  TERt4S  (Continue  on  reverse  if  necessary  and  identify  by  block  number) 
Software  Specification  Methodology  Guidelines 
Software  Specification  Tools  Software  Design  Methodo- 

o*y  lo£v 


19  ABSTRACT  (Continue  on  reverse  if  necessary  and  identify  by  b(ock  number) 

LThe  purpose  of  this  research  was  to  provide  the  Air  Force  system  and  software  development 
manager  with  an  uncomplicated  set  of  guidelines  for  matching  existing  methods  and  tools  to 
the  needs  of  specific  development  projects.  The  Specification  Technology  Guidelines  effort 
was  divided  into  five  major  tasks. 

The  first  task  studied  software  requirements  in  six  Air  Force  mission  areas.  Tn  the  perfor¬ 
mance  of  this  task  information  was  gathered  regarding  programming  characteristics,  software 
development  requirements,  and  the  support  environments  of  typical  application  software. 

Within  each  mission  area,  differences  in  application  and  development  of  software  most  affect¬ 
ing  methodology  selection  were  given  more  attention.  All  Air  Force  software  efforts  were 
deemed  to  fall  Into  18  generic  software  categories. 


20  DISTRIBUTION  '  AVAILABILITY  Of  ABSTRACT 
GuNClASSIFIED/UNLIMiTFO  El  SAME  AS  RPT 


22a  NAME  OF  RESPONSIBLE  INDIVIDUAL 

William  E.  Rzepka 


L'D  FORM  1473,  84  MAR  83APKe 


ACT  21  ABSTRACT  SECuBIIt  (  l  ASSiLiC.S'iON 

AS  RPT  n  DTlC  USERS  UNCLASSIFIED 


TF I  f  ■'Nt  (JOf/uc/p  Arp.3  )  I  •'•'t  Oi^iCf 
(315)  330-4063  I  RADC  (COEH) 


83  APR  i?<l,tiOn  moy  De  u%ed  urtii  ,  ✓  r  ^  (  \r  r  i*j  fu 

All  other  ed‘t ions  on?  ohS'/lPt*:* 


1^.*  M.X.. 


UNCLASSIFIEP 


PREFACE 

This  document  is  the  final  technical  report,  CDRL  Item  A002,  that  describes 
the  results  of  the  five  tasks  involved  in  developing  the  specification  technology 
guidelines  and  incorporating  them  into  a  Specification  Technology  Guidebook, 
CDRL  Item  A003.  This  report  was  prepared  in  accordance  with  the  statement 
of  work,  contract  F30602-84-C-0073.  It  summarizes  the  work  done  for  the 
Rome  Air  Development  Center  by  Boeing  Aerospace  Company  in  Kent,  Wash¬ 
ington. 

In  task  1  of  this  contract,  the  system  developments  in  which  the  Air  Force  uses 
computers  and  software  were  studied  and  organized  into  generic  categories.  As 
part  of  this  task,  a  telephone  survey  was  conducted  of  Air  Force  personnel  asso¬ 
ciated  with  software  developments  to  review  current  Air  Force  practice  and 
experience,  if  any,  with  specification  and  design  methodologies. 

In  task  2,  existing  system  requirements,  software  requirements,  and  software 
design  methodologies  were  studied  and  evaluated  with  respect  to  the  category 
of  system  and  life  cycle  phase  to  which  they  were  applicable. 

In  task  3,  a  set  of  guidelines  were  developed  for  the  software  manager  to  use  in 
selecting  a  coherent  specification  methodology  and  support  tools  to  meet 
specification  needs  of  system  requirements,  software  requirements,  and  software 
design  activities. 

In  task  4,  these  table-driven  selection  guidelines  were  documented  in  a  guide¬ 
book.  The  modular  design  that  the  tables  provide  simplify  the  use  of  the  guide¬ 
book  and  allow  it  to  be  expanded  to  include  new  methodologies  and  techniques. 
The  guidebook  also  describes  the  various  n  .;thodologies  and  tools  studied  in 
task  2. 

In  task  5,  the  guidelines  were  applied  to  three  example  problems  for  C^I 
software  development  projects.  A  primary  consideration  imposed  on  each 
example  was  compatibility  with  the  Ada*  programming  language.  The  other 
considerations  used  for  system  requirements  and  design  of  the  C^I  problems 
were  derived  from  actual  requirements  set  forth  in  C^I  RFP's,  and  working 
knowledge  of  the  requirements  for  C^I  software  and  system  projects  gained  by 
Boeing  Aerospace  engineers  during  the  last  decade. 


Ada  is  a  trademark  of  the  U.S.  Department  of  Defense  (Ada  Joint  Program  Office). 
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1.  PROJECT  OVERVIEW 

1.1.  Background 

During  the  1970’s,  many  techniques  and  tools  were  developed  to  support  system 
and  software  development  processes.  Most  development  concentrated  on  pro¬ 
gramming  and  testing  activities,  but  a  mini-proliferation  of  specification  and 
analysis  tools  occurred  for  supporting  the  front  end  life  cycle  activities:  system 
requirements  analysis,  software  requirements  analysis,  and  software  design. 
Complex  specification  methodologies  appeared  (e.g.,  that  were  based  on  data 
flow,  control  flow,  and  finite  state  machine  modeling  techniques,  among  others) 
and  incorporated  specialized  analysis  tools  (e.g.,  formal  languages,  graphical 
descriptions,  static  analyzers,  etc.).  Much  has  been  written  about  their  capabil¬ 
ities,  problem  domains,  and  relative  degrees  of  sophistication  and  success.  How¬ 
ever,  no  single  methodology  or  technique  is  universally  applicable  to  the 
specification  of  all  problem  environments. 

Rather  than  being  enlightened,  some  users  are  confused  by  this  proliferation  of 
methodologies  and  techniques  and  are  no  closer  to  understanding  which  metno- 
dology  best  fits  project  requirements.  This  situation  has  been  further  compli¬ 
cated  with  the  introduction  of  the  Ada  programming  language.  Users  must 
understand  which  of  the  methods  and  techniques  result  in  designs  taking  max¬ 
imum  advantage  of  the  software  engineering  principles  which  Ada  directly  sup¬ 
ports  and  implements. 

In  such  an  atmosphere,  the  technical  manager  is  confronted  with  many  claims, 
counter-claims,  comparisons,  and  evaluations  of  existing  specification  methods, 
most  of  which  are  uncorroborated.  No  efl“ective  focus  has  existed  for  aiding 
software  development  managers  during  selection  of  the  specification  methodol¬ 
ogy  or  tool  best  suited  to  their  problem.  The  Specification  Technology  Guide¬ 
lines  effort  was  conceived  to  provide  the  needed  focus  and  to  organize  metho¬ 
dologies  and  tools  information. 

1.2.  Project  Summary 

The  purpose  of  this  research  was  to  provide  the  Air  Force  system  and  software 
development  manager  with  an  uncomplicated  set  of  guidelines  for  matching 
existing  methods  and  tools  to  the  needs  of  specific  development  projects.  The 
Specification  Technology  Guidelines  effort  was  divided  into  five  major  tasks, 
described  briefly  in  the  following  paragraphs  (for  detailed  descriptions  refer  to 
sections  2.0,  3.0,  4.0,  .[i.O,  and  6.0  of  this  report). 

The  first  task  studied  software  requirements  in  six  Air  Force  mission  areas.  In 
the  performance  of  this  task  information  was  gathered  regarding  programming 
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characteristics,  software  development  requirements,  and  the  support  environ¬ 
ments  of  typical  application  software.  Within  each  mission  area,  differences  in 
application  and  development  of  software  most  affecting  methodology  selection 
were  given  more  attention.  All  Air  Force  software  efforts  were  deemed  to  fall 
into  18  generic  software  categories.  Section  2.0  of  this  report  describes  these 
categories  in  detail.  Summaries  of  the  Air  Force  missions  are  contained  in 
appendices  A  through  F  of  the  guidebook,  with  each  appendix  listing  the 
software  functions  for  that  mission,  by  software  categories. 

The  second  task  studied  existing  system  requirements  and  software  design 
methodologies.  Mature  methodologies  were  identified  (in  this  case  “mature” 
refers  to  methodologies  that  can  be  used  by  other  than  their  developing  organi¬ 
zation)  and  analyzed  to  determine  which  software  categories  they  satisfied  and 
the  life  cycle  phase(s)  to  which  they  applied.  Section  3.0  of  this  report 
describes  this  task  in  detail. 

The  third  task  used  information  from  the  first  two  tasks  in  constructing  guide¬ 
lines  that  aid  a  project  manager  in  selecting  methodologies  and  supporting  toob 
for  a  particular  software  category  and  life  cycle  phase.  The  guidelines  support 
and  technically  complement  system  requirements,  software  requirements,  and 
software  design  specification  activities.  Task  3  b  described  in  section  4.0  of  thb 
report. 

The  fourth  task  documented  the  results  of  the  first  three  tasks  in  a 
Specification  Technology  Guidebook  (hereafter  called  the  Guidebook).  The 
Guidebook  was  written  for  use  by  technical  managers  of  system  and  software 
development  projects  and  presents  step-by-step  procedures  and  explanations  for 
using  the  guidelines  developed  in  task  3.  The  Guidebook  abo  describes  how  a 
particular  methodology  and  its  products  will  satbfy  Air  Force  specification 
standards.  Task  4  is  detailed  in  section  5.0  of  this  report. 

The  fifth  task  developed  examples  detailing  use  of  the  Specification  Technology 
Guidebook.  The  three  examples  were  drawn  from  typical  C^l  software  develop¬ 
ment  projects.  The  first  example  approaches  methodology  selection  from  the 
viewpoint  of  requirements  capabilities  and  depicts  development  of  C^l  system 
software  for  interactive  displays.  The  second  example  approaches  methodology 
selection  from  the  viewpoint  of  design  capabilities  and  depicts  an  airborne 
software  system  for  use  on  an  unnamed  special  purpose  computer.  The  third 
example  approaches  methodology  selection  from  the  viewpoint  of  a  highly- 
skilled  manager  who  knows  the  capabilities  he  wants  in  a  methodology. 
Features  required  in  the  selected  methodologies  of  all  three  examples  included: 
data  base  management  (needed  for  storing  software  tools  and  life-cycle  products 
by  phase),  user  friendliness,  and  compatibility  of  life-cycle  products.  In  addi¬ 
tion,  the  selections  were  constrained  to  be  compatible  with  the  Ada 


programming  language.  Task  5  is  described  in  detail  in  section  6.0  of  this 
report. 


1.3.  Scope  of  Effort 

The  Guidebook  effort  was  constrained  to  select  among  existing  requirements 
and  design  methodologies  and  tools.  The  Guidebook  was  written  for  Air  Force 
managers  who  perform  daily  planning  and  execution  of  system  and  software 
acquisition  and  development.  As  such,  it  was  prepared  for  users  with  a  general 
technical  background,  who  are  not  necessarily  familiar  with  the  intricacies  of 
requirements  and  design  technology. 

1.4.  Brief  Description  of  Guidebook 

The  purpose  of  the  Guidebook  is  to  aid  the  technical  project  ma^'-ager  in  select¬ 
ing  specification  and  design  methodologies  for  a  given  project  and  life  cycle 
phase.  Three  different  table-driven  selection  paths  arc  provided,  along  with 
example  usage  of  each.  In  addition,  the  Guidebook  provides  paragraph  models 
that  will  aid  in  preparing  future  Statements  of  Work  that  stipulate  the  use  of 
particular  methodologies.  The  structure  of  the  Guidebook  is  illustrated  in 
figure  1-1. 

The  organization  of  the  Guidebook  permits  easy  access  since: 

(a)  A  novice  user  can  start  with  the  introduction, 

(b)  A  more  experienced  user  who  desires  to  select  a  requirements 
methodology  for  a  project  can  turn  to  section  2  of  the  Guidebook  and 
follow  the  instructions  describing  how  to  accomplish  that  selection 
(this  procedure  is  Path  1  in  the  Guidebook), 

(c)  A  mors  experienced  user  who  desires  to  select  a  design  methodol¬ 
ogy  for  a  project  can  turn  to  section  2  of  the  Guideb^xjk  and  follow 
the  instructions  describing  how  to  accomplish  that  selection  (this  pro¬ 
cedure  is  Path  2  in  the  Guidebook), 

(d)  A  very  experienced  user  who  knows  the  features  ae  wants  in  a 
methodology,  regardless  of  the  specification  phase,  can  turn  to  section 
2  and  follow  the  instructions  describing  how  to  select  a  methodology 
using  a  set  of  desired  capabilities  (this  procedure  b  ^ath  S  in  the 
Guidebook),  or 

(e)  Any  user  desiring  information  on  a  particular  methodology  or  tool 
can  turn  to  the  descriptions  in  section  4  of  the  Guidebook. 

The  following  paragraphs  describe  the  contents  of  the  Guidebook  on  a  section- 
by-section  basis. 
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Figure  1-1;  Guidebook  Organization 


The  first  section  introduces,  the  Guidebook,  discusses  its  purpose,  and  describes 
its  organization.  There  is  a  brief  discussion  of  the  need  for  appropriate 
specification  technology  and  how,  in  gen*;!  jh  the  Guidebook  should  be  iised 
during  selection. 

The  second  section  presents  guidelines  for  i  sing  the  table-driven  selection  paths 
(i.e..  Paths  1,  2,  and  3).  Our  table-driven  *ppioach  h.is  two  advantages: 

(1)  It  is  easy  to  follow  and  use  without  exJensive  training  or  reading, 
and 

(2)  the  tables  are  constructed  lor  e*»sy  expansion  to  incorporate  new 
methodologies  and  techniques  as  they  mature. 

The  third  section  provides  guidelines  i::  selecting  automated  took  i,hat  will 
support  candidate  methodologies. 

The  fourth  section  describes  methodologie".  and  automated  tool  sets. 

The  fifth  3^  ion  briefly  describes  pertmecl  .software  acquisition  life  cycles.  It 
discusses  Force  Phased  Acquisition  objectives  and  their  relation  to 
specificatiu  .ecnnologies  used  in  the  Gu>debook. 

The  sixtb  '  ction  provides  model  paragraphs  for  use  in  preparing  future  State¬ 
ments  of  '.Vork  (SOWs)  which  will  direct  the  use  of  specification  technologies  in 
the  develop  uent  of  Air  Force  Systems. 

Appendices  A  through  F  summarize  major  Air  Force  missions.  Major  functions 
within  each  mission  a^e  described  and  information  gathered  regarding  program¬ 
ming  c  laia-oteristics,  software  development  requirements,  and  the  support 
environ.'.iei.ts  of  typical  application  software.  Within  each  mission  area, 
differenes  in  application  and  developmens  of  software  most  affecting  methodol¬ 
ogy  select;  m  were  given  more  attention.  Mission  software  efforts  were  recom¬ 
posed  int<  18  generic  software  categories  (see  figure  1-2':.  Tables  in  the  appen¬ 
dices  list  he  software  functions  for  a  mission,  by  software  categories.  These 
tables  aic  the  user  in  fitting  his  proposed  software  development  into  one  of  the 
Guidtboolr  categories. 

2.  SUMI  IARY  OF  TASK  1 

2.1.  Categorize  Air  Force  System  Developments 

The  first  .ask  studied  Air  Force  missions  and  organized  system  developments 
into  broai..  generic  categories  relating  computers  and  softwere  development  to 
the  missicas.  These  system  categories  relate  software  functions  to  software 
categories  for  later  usage  in  methodology  selection.  The,  requirements  for 
s  lecificatii  d  technology  were  defined  for  each  software  categc  in  terms  of  the 
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SOFTWARE  CATEGORIES  TABLE 


Category 

Characteristics 

Description 

(1)  Arithmetic  Based 

Data  oriented 

Programs  that  do  pri¬ 
marily  arithmetic  (e.g., 
payroll  and  wind  tunnel 
data  analysis)  operations. 

A  real-time  environment 
is  not  necessary.  Small, 
throwaway  programs  for 
preliminary  analysis  also 
fit  in  this  category. 

(2)  Event  control 

Control-oriented  process¬ 
ing 

Does  real-time  processing 
of  data  resulting  from 
external  events.  An 

example  might  be  a  com¬ 
puter  program  that 

processes  telemetry  data. 

(3)  Process  control 

Control-oriented  process¬ 
ing 

Receives  data  from  an 
external  source  and  issues 
commands  to  that  source 
to  control  its  actions 
based  on  the  received 
data. 

(4)  Procedure  control 

Complex  processing 

Controls  other  software; 
for  example,  an  operating 
system  that  controls  exe¬ 
cution  of  time-shared  and 
batch  computer  programs. 

(S)  Navigation 

Complex  processing 

Does  computations  and 
modeling  to  compute 
information  required  to 
guide  an  airplane  from 
point  of  origin  to  destina¬ 
tion. 

(6)  Flight  Dynamics 

Control-dominated  com¬ 
plex  processing 

Uses  the  functions  com¬ 
puted  by  navigation 

software  and  augmented 
.  by  control  theory  to  con¬ 

trol  the  entire  flight  of  an 
aircraft. 

1  eontinueJ 

Category 

Characteristics 

Description 

(7)  Orbital  Dynamics 

Control-dominated  com¬ 
plex  proceaing 

Resembles  navigation  and 
flight  dynamics  software, 
but  has  the  additional 
complexity  required  by 
orbital  navigation,  such  as 
a  more  complex  reference 
system  and  the  inclusion 
of  gravitational  effects  of 
other  heavenly  bodies. 

(8)  Menage  processing 

Dstvdomin&ted  complex 
processing 

Handles  input  and  output 
messages,  processing  the 
text  or  information  con¬ 
tained  therein. 

(0)  Diagnostic  S/W 

Data-oriented  processing 

Used  to  detect  and  isolate 
hardware  errors  in  the 
computer  in  which  it 
resides  or  in  other 
hardware  that  can  com¬ 
municate  with  that  com¬ 
puter. 

(10)  Sensor  uid  sign&l  pro¬ 
cessing 

Control-dominated  com¬ 
plex  processing 

Similar  to  that  of  message 
processing,  except  that  it 
requires  greater  process¬ 
ing,  analysing,  and 

transforming  the  input 
into  a  usable  data  process¬ 
ing  format. 

(11)  Simulation 

Complex,  depending  on 
entity  being  simulated 

Used  to  simulate  an 
environment,  mission 

situation,  other  hardware, 
and  inputs  from  these  to 
enable  a  more  realistic 
evaluation  of  a  computer 
program  or  a  piece  of 
hardware. 

(12)  Database  manage¬ 
ment 

Data-oriented  processing 

Manages  the  storage  and 
access  of  (typically  large) 
groups  of  data.  Such 
software  can  also  often 
prepare  reports  in  user- 
deflned  formats,  based  on 
the  contents  of  the  data¬ 
base. 

Figure  1-2  Software  Categories  Table  (part  2  of  3) 


etntUued 

Categoiy 

Characteristics 

Description 

(13)  Dat»  Acquisition 

Control-dominated  com¬ 
plex  processing 

Receives  information  in 
real-time  and  stores  it  in 
some  form  suitable  for 
later  processing;  for  exam¬ 
ple,  software  that  receives 
data  from  a  space  probe 
and  files  it  for  later 
analysis. 

(14)  Dkta  presentation 

Data-oriented 

Formats  and  transforms 
data,  as  necessary,  for 
convenient  and  under¬ 
standable  displays  for 
humans.  Typically,  such 
displays  would  be  for 
some  screen  presentation. 

(15)  Decision  and  planning 
aids 

Data-dominated  complex 
processing 

Uses  artificial  intelligence 
techniques  to  provide  an 
expert  system  to  evaluate 
data  and  provide  addi¬ 
tional  information  and 
consideration  for  decision 
and  policymakers. 

(16)  Pattern  And  linage 
proeeasing 

Data-docninated  complex 
processing 

Used  for  computer  image 
generation  and  processing. 
Such  software  may 

analyse  terrain  data  and 
generate  images  based  on 
stored  data. 

(17)  Computer  system 
Software 

Data-oriented 

Provides  services  to  opera¬ 
tional  computer  programs 
(i.e.,  problem-oriented). 

(18)  Software  development 
tools 

Datvoriented 

Provides  services  to  aid  in 
the  development  of 

software  (e.g.,  compilers, 
assemblers,  static  and 
dynamic  analysers). 

life  cycle  development  activities  of  system  requirements  analysis,  software 
requirements  analysis,  and  software  design.  These  specification  technology 
requirements  are  built  into  the  tables  presented  in  Guidebook  section  2.0.  The 
requirements  were  based  on  considerations  of  available  technology  and  the  for¬ 
mats  prescribed  by  current  Air  Force  specification  standards  (MIL-STD-490, 
Specification  Practices,  30  Oct  68)  for  system  and  software  requirements  and 
software  design  documentation.  At  the  kick-off  meeting  held  at  RADC  in  April 
1984,  it  was  agreed  to  support  MIL-STD-SDS  (to  be  released  as  MIL-STD- 
2167). 

We  suggested  starting  with  the  standard  software  categories  defined  in  the 
Software  Test  Handbook  produced  under  RADC  contract  number  F30602-82- 
C-0050,  and  relating  these  categories  to  the  major  Air  Force  missions.  These 
categorical  relationships  were  successfully  used  in  developing  the  Soft  .  are  Test 
Handbook. 

To  assure  that  the  results  of  the  previous  handbook  were  applicable  for  our 
research,  we  undertook  an  informal,  updating  survey  of  current  Air  Force  mis¬ 
sion  usage  of  requirements  and  design  methodologies  for  software  development. 
Survey  results  are  detailed  in  section  2.2.  The  survey  showed  that  no  basic 
structural  changes  would  be  required  in  adopting  the  approach  taken  by  the 
Software  Test  Handbook,  although  we  separated  the  Missile/Space  mission 
description  into  independent  appendices,  resulting  in  six  appendices  instead  of 
five.  Additionally,  minor  changes  were  made  in  mission  descriptions  to  account 
for  our  focus  on  software  development  requirements  instead  of  software  testing 
requirements. 

2.2.  Survey  of  Air  Force  Requirement  Specification  Problems 

This  survey  of  Air  Force  personnel  (both  civilian  and  military)  determined  gen¬ 
eral  and  specific  problems  in  preparation  and  analysis  of  requirement 
specifications,  and  examined  methodology  and  tool  experience. 

Since  Boeing  proposed  using  existing  descriptions  of  Air  Force  missions,  and  the 
software  functions  and  software  categories  used  in  the  Software  Test  Handbook 
(RADC  contract  F30602-82-C-0050),  the  survey  determined  which  changes  to 
this  informational  base  were  needed. 

2.2.1.  Survey  Participants 

The  initial  interview  list  comprised  Air  Force  personnel  contacted  during  the 
Software  Test  Handbook  survey.  Each  contact  was  asked  to  recommend  other 
individuals  with  pertinent  experience  in  software  development  and  use  of 


specificatioQ  methodologies  and  tools.  A  total  of  32  contacts  were  made,  and  25 
extended  interviews  held. 

Most  participants  were  military  and  civilian  Air  Force  personnel  in  all  six  Air 
Force  mission  areas,  and  included  staff  and  project  personnel  at  various  levels  of 
responsibility.  Additionally,  we  talked  with  personnel  from  DoD,  Aerospace 
Corporation,  and  MITRE  Corporation. 

2.2.2.  Survey  Results 

The  relatively  informal  survey  was  structured  so  that  each  participant  was 
asked  tho  same  general  questions.  Survey  questions  fell  into  five  groups,  and 
are  discussed  in  the  following  sections.  Of  course,  the  discussions  often  ranged 
widely  afield,  depending  on  the  experience  and  interests  of  each  participant; 
these  chats  often  provided  additional  insights. 

2.2.2.1.  Question  1:  Major  Problem  Areas 

One  survey  participant  said  the  major  problem  with  requirement  specifications 
is  that  “we  still  don’t  know  how  to  write  an  effective  one.”  Most  of  those  sur¬ 
veyed  did  not  respond  so  strongly,  but  felt  there  were  major  problems  in  the 
specification  of  systems  and  software.  The  descriptions  of  major  problem  areas 
tended  to  fall  into  three  categories: 

(1)  The  ambiguity  of  specifications  -  Requirement  specifications  are 
written  by  the  contractor  to  be  understood  by  Air  Force  acquisition 
organizations;  as  a  result,  some  users  had  trouble  understanding  the 
language  of  the  specification  and  felt  they  couldn’t  intelligently  com¬ 
ment  on  it. 

(2)  Difficulty  in  generating  a  B-level  specification  from  an  A-level 
specification  -  In  a  study  of  the  Space  Division  mission,  an  excellent 
^  spec  was  the  single  most  critical  element  in  a  successful  system 
development. 

(3)  The  time  consuming  tracing  of  requirements  from  concept 
definition  through  system  test  -  This  task  is  deemed  enormously 
important  and  is  currently  being  accomplished  by  hand. 

2.2.2.2.  Question  2:  Unique  Problems  of  Specific  Air  Force  Missions 

A  surprising  survey  result  was  that  almost  every  participant  said  that  they  had 
no  unique  requirement  specification  problems  characteristic  of  their  area. 

Several  participants  identified  unique  characteristics  of  their  product  areas,  such 
as  the  unit  cost  of  armaments,  the  high  reliability  required  of  spacecraft,  and 
the  many  human  interfaces  in  systems.  Few  of  these  problems  were  truly 
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problems  of  specifying  requirements;  the  problems  were,  instead,  specific  cases 
of  the  general  problems  encountered  by  all. 

2.2.2.3.  Question  3:  Experience  with  Methodologies  and  Tools 

Most  of  those  surveyed  did  not  use  any  methodology  or  tool  as  part  of  their 
standard  practice.  Few  had  used  more  than  one  methodology  or  tool.  None 
considered  that  their  use  of  any  methodology  or  tool  had  been  a  success,  nor 
did  anyone  know  of  a  success  story  from  others. 

PSL/PSA  (and  CADSAT,  its  military  equivalent)  seemed  the  best  known  tool. 
Second  most  frequently  mentioned  was  Docwriter  (now  called  TEMSE).  How¬ 
ever,  only  a  fraction  of  the  participants  had  direct  experience  with  either. 

2.2.2.4.  Question  4:  Requirements  Tracking  and  Most  Critical  Phases 

We  asked  each  survey  participant  about  the  need  for  requirements  tracking, 
and  to  identify  the  life  cycle  phases  when  this  need  was  most  critical.  Almost 
everyone  felt  that  there  was  a  strong  need  to  be  able  to  track  requirements. 
The  two  most  frequently  mentioned  phases  were  (1)  the  transition  from  user 
need  to  system  specification,  and  (2)  the  transition  from  system  specification  to 
a  B-level  spec.  A  significant  fraction  declined  to  identify  any  phase  as  being 
most  critical. 

One  icoroclast  said  that  requirements  tracing  was  no  real  problem;  and  that  it 
was  simply  a  bookkeeping  job.  He  further  stated  that  all  the  methodologies 
and  tools  were  attempting  to  solve  the  wrong  problem.  His  estimation  was  that 
these  toob  addressed  only  five  percent  of  the  total  task.  He  felt  the  major 
problem  was  the  creative,  inventive  analysb  required  when  going  from  user 
needs  to  system  spec,  from  system  spec  to  segment  spec,  and  from  segment  spec 
to  B-level  spec.  Hb  opinions  were  not  seconded  elsewhere. 

2.2.2.5.  Question  5:  Rapid  Prototyping 

Most  of  those  surveyed  agreed  that  a  rapid  prototyping  capability  sounded 
attractive,  but  said  they  did  not  know  how  to  accomplbh  it  and  that  they 
doubted  any  usable  capability  would  be  available  soon.  Several  said  that  it  was 
entirely  the  responsibility  of  the  contractor. 

2.2.3.  Effect  of  Survey  on  Specification  Technology  Guidebook 

The  survey  provided  no  informrtion  that  required  changing  the  standard 
software  categories  used  in  the  Software  Test  Handbook.  It  did,  however,  pro¬ 
vide  insight  into  the  problems  faced  by  the  Air  Force  in  the  specification  and 
use  of  requirements;  and  that  insight  helped  us  produce  a  more  usable  and 
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relevant  guidebook. 

3.  SUMMARY  OF  TASK  2 

3.1.  Evslaste  Current  Methodologies 

We  identified,  categorized,  and  characterized  specification  technology  metho¬ 
dologies  and  automated  tools  that  were  suitable  for  practical  application  to  Air 
Force  mission  software  development  projects.  Although  the  number  of  metho¬ 
dologies  described  in  the  computer  science  and  software  engineering  literature 
was  considerable,  we  selected  12  methodologies  for  evaluation.  The  considera¬ 
tions  we  used  in  their  selection  are  described  in  section  3.2  below. 

Each  of  the  12  methodologies  was  categorized  by  its  primary  philosophy  of 
requirements  and  design  specification.  The  requirements  analysis  categories 
(i.e.,  the  way  a  requirements  methodology  models  the  system  to  be  produced) 
are: 

1.  Flow-oriented  -  models  the  system  in  terms  of  control  or  data  fiow. 

2.  Finite-state  machine  -  modeb  state  of  system  and  transitions 
between  states. 

3.  Object-oriented  -  modeb  the  entities  (objects,  concepts,  processes) 
in  the  system,  including  relationships  among  them  and  events  and 
mechanbms  that  change  them. 

The  design  categories  are: 

1.  Decomposition  -  guided  either  by  function,  control,  or  data 
hierarchical  relationships. 

2.  Encapsulation  -  producing  either  data  or  process  abstractions. 

3.  Data  Structured  -  guided  by  inherent  relationships  among  input 
and  output  data  items. 

4.  Programming  Calculus  -  guided  by  assertions  about  the  effect  a 
series  of  statements  must  produce. 

We  developed  a  standard  format  for  characterizing  each  methodology.  The  for¬ 
mat  is  a  composite  of  characteristics  found  in  three  different  sources:  (1)  the 
Methodman  /  report,  (2)  a  study  done  by  Hughes  Aircraft  Company  entitled 
Reusable  Software  Implementation  Technology  Reviews,  and  (3)  Boeing  internal 
studies  of  software  engineering  methodologies  and  toob.  We  used  a  similar 
form  to  characterize  automated  tool  sets.  Appendix  A  of  this  report  contains 
an  annotated  copy  of  both  formats. 

Boeing  software  engineers  with  relevant  expertise  in  specification  technologies 
reviewed  and  concurred  with  our  evaluations  of  methodologies  and  tools. 
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3.2.  Criteria  for  Inclusion 

The  major  criterion  for  inclusion  of  a  methodology  was  “maturity  such  that  the 
methodology  could  be  used  by  organizations  other  than  their  originators."  This 
criterion  encourages  inclusion  of  all  the  common  methodologies  that  have  been 
repeatedly  field  tested  and  their  results  weU  documented;  it  excluded  in-house 
methodologies  developed  by  a  company  for  its  own  use,  in  accordance  with  its 
own  standards.  Thus,  we  evaluated  a  group  of  methodologies  that  are  as 
representative  of  state  of  the  practice  of  specification  technology  as  possible. 

The  emphasis  on  maturity  immediately  eliminated  from  consideration  those 
methodologies  which  are: 

a.  theoretical  descriptions  never  implemented, 

b.  academic  exercises  developed  to  prove  a  particular  technique  is 
feasible,  and 

c.  developments  in  progress  as  knowledge  enpneering  (expert  system) 
research  projects.^ 

The  methodologies  we  characterized  are  listed  below. 


DSSD 

HDM 

SADT 

SA/SD 

SCR 

SREM 

VDM 

DCDS 

JSD 

PAISLey 

SARA 

USE 


Data  Structured  Systems  Design 
Hierarchical  Development  Method 
Structured  Analysis  and  Design  Technique 
Structured  Analysis  and  Structured  Design 
(Realtime  Yourdon) 

Software  Cost  Reduction  -  Navy 

Software  Requirements  Engineering  Methodology 

Vienna  Development  Method 

Distributed  Computing  Design  System 

Jackson  System  Design 

Process-oriented,  Applicative, 

Interpretable  Specification  Language 
System  ARchitect’s  Apprentice 
User  Software  Engineering  Methodology. 


DSSD,  SADT,  SA/SD,  and  SREM  are  well-known,  well-exercised,  basic  metho¬ 
dologies.  They  were  developed  from  research  performed  in  the  early  1970’s  in 
response  to  the  crisis  m  software.  Many  DoD  contractors  use  “customized” 
methodologies  having  strange  names,  but  most  of  these  methodologies  are,  in 
fact,  closely  related  to  the  four  methodologies  above.  Before  a  contract  officer 


1.  The  field  of  knowledge  engineering  is  itself  in:)mature. 


rejects  a  methodology  proposed  by  a  company,  the  question  might  first  be 
asked:  “On  which  methodology  is  this  one  based?”  It  may  prove  acceptable  as 

is,  or  the  company  may  accept  a  recommendation  to  use  its  “parent”  methodol¬ 
ogy  in  its  place. 

HDM  and  VDM  are  representative  of  specification  technologies  based  on  formal 
specification  languages.^  They  have  been  successfully  used  outside  their 
developing  organizations  on  significant  projects. 

DCDS  is  the  methodology  being  developed  as  an  extension  of  SREM  to  distri¬ 
buted  systems  design. 

SCR  and  JSD  are  representative  of  technologies  based  on  the  characteristics  of 
abstraction  and  encapsulation.  SCR  has  seen  use  by  the  Navy  and  Bell  Labs. 
JSD  is  commercially  available  in  England. 

PAISLey  is  representative  of  a  trend  to  operational  (prototyping)  requirements 
specification  methodologies.^  PAISLey  is  not  truly  mature  in  the  sense  that  it 
has  been  used  by  any  organization  other  than  its  originator.  However,  the 
methodology  was  developed  expressly  for  embedded  systems.  For  development 
of  less  than  life-critical  software,  the  benefits  should  outweigh  the  risk  of  using 

it. 

SARA  and  USE  are  representative  of  technologies  developed  in  university  set¬ 
tings  that  are  full-scale  methodologies,  rather  than  feasibility  demonstrations  of 
single  ideas. 

Some  methodologies  were  excluded  from  evaluation  because  the  information  we 
could  gather  on  them  was  too  meager.  This  is  particularly  a  problem  with 
methodologies  developed  outside  the  United  States,  where  language  and  time 
barriers  complicate  our  acquiring  information  on  them. 

The  past  year  has  seen  the  release  and  publication  of  material  about  metho¬ 
dologies  billing  themselves  as  Ada  compatible  or  object-oriented  (implying  com¬ 
patibility  with  Ada).  In  some  cases,  these  announcements  relate  to 
modifications  of  existing  methodologies  and  can  be  considered  as  additional 
information  about  them.^  The  basic  description  of  these  methodologies  is  not 
appreciably  altered  by  such  modifications,  except  that  now  it  can  include  text 
about  Ada  compatibility.  In  other  cases,  the  announcements  describe  methods 
that  can  be  incorporated  into  existing  methodologies  to  increase  the  Ada  com¬ 
patibility  of  produced  designs. 

2.  Affirm,  CLEAR,  Ordinary,  SDM,  Z,  SLAN-4,  and  LARCH  are  other  methodologies  in 
this  category. 

3.  GIST  is  another  methodology  in  this  category. 

4.  ANNA  is  an  exception  to  either  case,  in  that  it  is  an  entirely  new  methodology 
designed  for  Ada  compatibility.  Unfortunately,  material  on  ANNA  was  not  readily  avail- 


3.3.  Tool  Evaluations 

There  are  literally  thousands  of  commerciaDy  available  software  packages 
(software  tools)  that  claim  to  assist  requirements  analysis  and  design.  It  was 
impractical  to  review  them  all  during  this  effort.  We  concentrated,  instead,  on 
reviewing  and  classifying  tool  sets  that  support  particular  methodologies 
through  the  specification  phases  of  software  development.  Our  reason  for  doing 
this  was  simple:  tools  tailored  specifically  to  the  methodology  are  much  more 
effective  than  generic  tools.  And  finally,  most  methodologies  already  have  a  set 
of  software  tools  developed  for  them  (e.g.,  REVS  is  tailored  specifically  for 
SREM). 

When  methodologies  (DSSD,  HDM,  SREM,  DCDS,  PAISLey,  SARA,  USE)  had 
tool  sets  developed  specifically  for  them,  we  described  both  the  methodology 
and  tool  set  features  in  the  methodology  description  section  of  the  Guidebook. 
We  did  not  describe  these  tool  sets  a  second  time  in  the  software  tools  section. 
We  evaluated  one  tool  set  (TAGS®)  for  use  with  SADT  and  three  tool  sets 
(ARGUS,  EXCELERATOR,  PROMOD)  for  use  with  SA/SD.  TAGS  is  cer¬ 
tainly  the  best  tool  set  based  on  SADT.  There  are  at  least  four  more  tool  sets 
available  for  SA/SD  that  we  did  not  review.  We  confined  our  evaluations  to 
tool  sets  for  which  we  found  software  engineers  having  hands-on  experience 
with  the  product  (e.g.,  characteristics  like  usability  require  actual  experience  to 
be  properly  evaluated). 

We  treated  PSL/PSA  as  a  generic  automated  tool  set  useful  both  in  project 
support  and  documentation.  PSL/PSA  can  be  used  with  several  methodologies 
(i.e.,  particularly  helpful  to  those  performing  data  flow  analysis). 

4.  SUMMARY  OF  TASK  3 
4.1.  Define  Selection  Guidelines 

We  developed  guidelines  to  aid  a  project  manager  in  selecting  a  final  candidate 
methodology  and  supporting  tools  for  a  particular  software  category  and  life 
cycle  phase.  This  selection  process  matches  the  methodology’s  abstract  model¬ 
ing  capability  to  the  conceptual  needs  of  the  software  category  and  life  cycle 
phase.  In  doing  this  we  have  fulfilled  the  explicit  requirements  of  the  Statement 
of  Work  (SOW)  for  the  effort.  But,  the  guidelines  we  developed  also  fulfill  the 
implicit  requirements  of  the  SOW  in  terms  of  practicality  of  a  selected 

able  until  February  1985,  too  late  for  inclusion  in  the  Specification  Technology  Guide¬ 
book. 

5.  Also  known  as  lORL. 


I 

» 

i 

i 

1 

i 

i 


I 

I. 

* 

■ 

r 

I 

I 

( 

i 

( 

i 

i 

'j 


methodology  to  a  project.  Our  guidelines  match  the  relative  power  of  the 
methodology  and  support  tools  to  the  relative  significance  of  the  development 
project.  This  extends  the  original  intent  of  the  SOW,  and  effectively  tailors 
final  selection  to  the  project. 

The  guidelines  were  set  up  to  hide  the  identity  of  candidate  methodologies  until 
selection  b  completed.  Thb  blind  selection  process  mitigates  the  effects  of 
selector  bias  and  acquaints  the  selector  with  methodologies  he  might  otherwbe 
never  consider. 

The  selection  guidelines  provide  three  different  paths.  The  first  two  paths 
require  the  user  to  rate  the  significance  of  the  project  and  to  determine  its 
software  category.  Once  project  significance  and  software  category  are  deter¬ 
mined,  the  user  can  choose  Path  1  and  base  selection  on  the  requirements 
specification  phase;  or  Path  2  and  base  selection  on  the  design  specification 
phase.  Path  3,  provided  for  the  experienced  manager,  bypasses  significance  rat¬ 
ing  and  software  categorization,  and  allows  the  manager  to  base  selection  on 
individual  methodology  capabilities  needed  for  a  project. 

4.2.  Significance  Level  Determination 

A  common  sense  notion  in  software  development  b  that  a  methodology  for  a 
project  should  be  appropriate  to  the  size  of  the  project.  Dbcussions  in  the 
literature  about  the  differences  in  programming-in'tke'SmaU  versus 
programming-in'the-large  are  elaborations  of  thb  notion. 

Our  significance  level  concept  b  a  refinement  of  the  notion  of  project  size.  We 
developed  thb  concept  because  projected  raw  count  of  source  code  statements, 
in  itself,  b  not  a  sufficient  discriminator  for  choosing  one  methodology  over 
another.  For  example,  formal,  verifiable,  complex  methodologies  normally  con¬ 
sidered  more  appropriate  to  large  projects  might  be  recommended  for  small  pro¬ 
jects  involving  life-critical  decbions. 

The  significance  level  concept  examines  the  software  development  project  from 
three  viewpoints:  project  considerations,  software  considerations,  and  quality 
considerations.  Under  project  considerations,  cost,  criticality,  and  schedule, 
measure  the  importance  of  funding  agency  attributes  to  the  project.  Under 
software  considerations,  complexity,  development  formality,  and  software  util¬ 
ity,  measure  the  conceptual  effort  required  by  the  project,  and  thus  measure  the 
significance  of  the  project  to  its  developers.  Under  quality  considerations,  relia¬ 
bility,  correctness,  maintainability,  and  verifiability  measure  the  importance 
end-users  attribute  to  the  project. 

Quality  considerations  exist  other  than  the  four  listed  above.  We  incorporated 
only  those  considerations  that  were  independent  of  software  category.  Two 
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reasons  support  this  decision. 

(1)  Simplification  -  Since  the  guidelines  describe  a  manual  system, 
additional  quality  considerations  would  have  meant  the  addition  of 
worksheets  (as  many  as  18),  one  for  each  software  category. 

(2)  Clarity  •  The  relationship  of  the  unused  quality  attributes  to  indi¬ 
vidual  software  categories  is  not  straightforward. 

4.2.1.  Considerations 

The  relationship  of  each  consideration  to  significance  level  is  explained  below. 

Project  Considerations 

(1)  Cost  -  The  significance  of  a  project  increases  in  direct  proportion 
to  relaxation  of  constraints  on  cost.  A  low  budget  with  tight  con¬ 
straints  indicates  a  lower  significance  than  a  relatively  unconstrained 
budget. 

(2)  Criticality  -  The  significance  of  a  project  rises  in  direct  proportion 
to  the  criticality  of  the  assignment.  A  project  in  which  flight  crew 
safety  is  involved  is  more  significant  than  one  whose  failure  would  be 
of  nuisance  impact  to  its  users. 

(3)  Schedule  -  The  significance  of  a  project  increases  in  direct  propor¬ 
tion  to  relaxation  of  constraints  on  scheduling.  A  project  with  tight 
controls  on  scheduling  is  less  significant  than  one  whose  schedule  can 
slip  in  order  to  get  the  software  ‘right’. 

Software  Considerations 

(4)  Complexity  -  The  significance  of  a  project  rises  in  direct  proportion 
to  the  complexity  of  the  solution.  A  difficult  problem  whose  solution 
is  hard  to  validate  is  more  significant  than  a  problem  whose  solution  is 
straight-forward  and  easy  to  check. 

(5)  Development  Formality  -  The  significance  of  a  project  rises  in 
direct  proportion  to  the  desired  level  of  contractor  controls.  The 
stronger  the  control  (and  the  more  formal  the  review  of  interim 
results),  the  more  significant  the  project. 

(6)  Software  Utility  -  The  significance  of  a  project  rises  in  direct  pro¬ 
portion  to  the  utility  of  the  application.  Software  developed  as  a 
one-shot  feasibility  demonstration  is  less  significant  than  software 
developed  to  provide  real-time  support  to  a  C^l  task. 
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Quality  Considerations 

(7)  Reliability  -  The  significance  of  a  project  rises  in  direct  proportion 
to  level  of  reliability  needed.  Software  that  should  respond  correctly 
to  nominal  conditions  is  less  significant  than  software  which  must 
have  its  faults®  removed  as  soon  as  they  occur. 

(8)  Correctness  •  The  significance  of  a  project  rises  in  direct  propor¬ 
tion  to  level  of  correctness  needed.  From  a  specification  point  of  view, 
level  of  correetnesa  is  a  measure  of  how  completely  the  software  or  its 
design  satisfies  project  requirements  and  constraints.  Software  that  is 
considered  acceptable  when  its  operation  providas  the  functionality 
needed  even  though  it  does  not  meet  other  constraints  (such  as  a 
user-friendly  interface)  is  less  significant  than  software  whose  design 
must  be  formally  validated  against  the  requirements  specification. 

(9)  Maintainability  -  The  significance  of  a  project  rises  in  direct  pro¬ 
portion  to  the  level  of  maintainability  needed.  Software  that  is  not 
expected  to  be  maintained  is  of  less  significance  than  software 
expressly  developed  so  that  the  extent  of  changes  are  optimally  local¬ 
ized. 

(10)  Verifiability  -  The  significance  of  a  project  rises  in  direct  propor¬ 
tion  to  the  level  of  verifiability  needed.  Software  whose  documenta¬ 
tion  is  to  be  casually  maintained  in  its  source  code  is  of  less 
significance  than  software  whose  documentation  is  complete  (includes 
requirements  through  source  code  documents)  and  always  up-to-date. 

4.2.2.  Characteristics  of  Each  Significance  Level 

A  project  of  significance  level  0  has  the  following  characteristics: 


6.  A  fault  is  an  undesirable  response  to  anomalous  conditions. 


-  ^ow  Budget,  emphasis  on  minimum  cost 

-  No  criticality  assignment 

-  Vight  Schedule 

-  Straight-forward  solution;  easy  to  checkout 

-  Few  defined  requirements;  informal  development; 

«wed  locally 

-  One-shot;  Prototype;  Test  Software;  Demonstration  Software 

-  Respond  correctly  to  nominal  conditions 

-  Functionality  met;  constraints  ignored 
No  maintenance  expected 

-  Documentation  in  source  code 

Test  ge aerators,  conversion  table  programs,  and  trade  study  simulations  are 
exampUs  of  projects  that  would  have  significance  level  0. 

A  proje'.t  of  significance  level  1  has  the  following  characteristics; 

'  Normal  cost  constraints 

-  Nuisance  Impact 

-  Some  schedule  constraints 

-  Moderate  Complexity 

-  Normal  to  Strong  Contractor  Controb 

-  Ground  Based  Software;  Data  Reduction; 

Mbsion  Prep  Software 

-  F aults  corrected  periodically; 

temporary  workarounds  provided 

-  F unctionality  and  constraints  met 

-  Predict  impact  of  changes 

-  Source  code  documentation  updated 


Editors,  compilers,  mbsion  and  environmental  simulators  are  examples  of  pro¬ 
jects  that  would  have  significance  level  1. 
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A  project  of  significance  level  2  has  the  following  characteristics: 

-  Some  Cost  Flexibility 

-  Mission  Impact 

-  Normal  Schedule  Constraints 

-  Greater  Complexity 

-  Strong  Contractural  Controls;  Formal  Reviews 

-  Realtime  Avionics,  C^  and  C^I  software 

-  Faults  removed  ASAP 

-  Implementation  validated  against 
design  specification 

-  Impact  of  changes  somewhat  localized 

-  Full  complement  of  documentation; 

design  documentation  upda*^ed  too 

AWACS,  ALCM,  PMALS,  C^I,  and  Avionics  mission  planning  arc  examples  of 
projects  that  would  have  significance  level  2. 

A  project  of  significance  level  3  has  the  following  characterbtics: 

-  Cost  not  predominant  factor; 

relatively  unconstrained 

-  Nuclear,  flight  crew  safety 

•  Additional  fault  detect  requirements  wiU 
not  impact  schedule 

-  Difllcult  Problem;  Complex  Solution; 

Hard  to  Validate 

-  Generally  Contracted  Rigid  Controls 
Over  Development 

-  Highly  Critical  Applications;  Possible 
Catastrophic  Results 

-  No  faults 

-  Design  validated  against  requirements  specification 

-  Extent  of  changes  optimally  localized 

-  Requirements  through  source  code  documentation 

always  up-to-date 

Nuclear  control  and  life-critical  software  are  examples  of  projects  that  would 
have  significance  level  3. 


4.3.  Methodology  Power  Rating 

We  rated  thirty  individual  capabilities  for  each  methodology.  Six  capabilities 
were  useful  for  requirements  specification: 


state  modeling 
data  flow  modeling 

control  flow  modeling 


object  modeling 
timing  performance 
specification 
accuracy  performance 
specification 


Fourteen  were  useful  for  design  specification: 


functional  decomposition 
data  decomposition 
control  decomposition 
data  abstraction 
process  abstraction 
data  base  definition 
con  currency /synchronization 
specification 


module  interface  definition 
formal  verification 
configuration  management 
completeness  analysis 
consistency  analysis 
Ada  compatibility 
notation  for  code  behavior 


Ten  were  independent  of  life  cycle  phase: 


prototyping 
test  plan  generation 
automated  tools  available 
traceability 

transition  between  phases 


validation 

usability 

maturity 

training/experience  level 
MIL-STD  documentation 


Each  capability  was  rated  on  a  scale  of  0  to  3,  where  0  is  no  support  and  3 
most  support.  The  actual  definitieas  of  these  numbers  for  a  specific  capability 
is  found  in  Appendix  B.  In  general,  the  factors  that  determine  the  relative 
power  of  one  methodology  over  another  are: 

(a)  formality  of  notation, 

(b)  complexity  of  specification  produced, 

(c)  rigor  of  mathematical  foundation,  and 

(d)  degree  of  automated  support. 


4.4.  Fitting  Methodology  to  Phase,  Category,  and  Significance 
Paths  1  and  2  of  the  guidelines  lead  to  methodology  selection  based  on  life-cycle 
phase,  software  category,  and  significance  level.  Path  1  differs  from  Path  2  by 
life-cycle  phase;  path  1  is  concerned  with  requirements  specification  and  path  2 
with  design  specification.  Methodologies  are  fitted  to  software  categories  by 
tables  that  list  desired  capabilities  by  software  category.  The  tables  permit 
matching  methodology  concepts  desired  by  a  user  to  concepts  needed  for  a  par¬ 
ticular  category.  Methodologies  are  related  to  project  significance  by  tables 
comparing  them  against  a  fictional  ideal  methodology  (one  that  provides  only 
the  capabilities  desired,  at  exactly  the  level  of  support  wanted).  We  assumed  a 
uniform  level  of  support  for  all  capabilities  desired;  that  is,  each  capability 
should  provide  the  same  level  of  support  as  the  overall  significance  rating  of  the 
project. 

Path  3  of  the  guidelines  permits  the  experienced  manager  to  choose  the  set  of 
capabilities  he  desires  in  a  methodology.  It  also  permits  him  to  select  a  non- 
uniform  level  of  support  for  the  chosen  capabilities. 

5.  SUMMARY  OF  TASK  4  -  BUILD  THE  GUIDEBOOK 

The  Specification  Technology  Guidebook,  which  documents  the  guidelines 
developed  in  the  Task  2,  was  designed  ufing  the  Software  Test  Handbook 
(RADC-TR-84-53,  Vol  II)  as  a  model.  Test  Handbook  organization  was 
reviewed  for  its  applicability  to  the  Guidebook,  and  for  its  usefulness  to  techni¬ 
cal  managers  of  system  and  software  development  projects.  We  found  the  basic 
structure  of  the  Test  Handbook  to  be  satisfactory  for  the  Specification  Technol¬ 
ogy  Guidebook.  The  organization  is  shown  in  Figure  1-1. 

The  design  of  the  selection  paths  and  the  tables  that  support  them  was  a  very 
complex  and  time-consuming  process.  Our  goal  was  to  design  a  table-driven 
selection  methodology  that  would  include  all  the  important  considerations  and 
that  could  be  easily  used.  The  design  originally  proposed  omitted  life  cycle 
phases  and  relative  significance  of  the  project  as  considerations  for  selection  cri¬ 
teria.  We  decided  any  selection  criteria  would  prove  inr.dequate  if  it  merely 
indicated  methodology  capabilities  without  addressing  how  well  those  capabili¬ 
ties  were  supported. 

The  second  design,  produced  during  the  contract,  included  all  important  con¬ 
siderations,  but  required  the  user  to  make  many  (up  to  50)  small  arithmetic  cal¬ 
culations.  We  decided,  in  the  interests  of  user  friendliness  and  simplification,  to 
design  tables  with  the  scoring  precalculated.  Accomplishing  this  required  over 
1700  computations,  but  our  third  design  successfully  removed  most  of  the 
drudgery  from  guidelines  usage. 
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An  additional  benefit  of  the  table-driven  selection  approach  is  that  the  tables 
can  be  easily  modified  to  refiect  new  capabilities  for  existing  specification  and 
design  technologies,  as  they  are  developed. 

The  future  penalty  for  the  precalculated  simplicity  of  the  selection  process  is 
that  more  work  will  be  required  to  modify  or  revise  the  methodology  score 
tables.  For  each  methodology  added  or  updated,  someone  must  compute  new 
scores  for  software  category,  life  cycle  phase,  and  significance  level  Instructions 
for  adding  new  methodologies  and  computing  scores  for  the  tables  are  in  Sec¬ 
tion  7.0  of  this  report. 

The  Air  Force  Mission  appendices  from  the  Software  Test  Handbook  were 
revised  and  updated  for  inclusion  in  the  Specification  Test  Guidelines.  The 
most  significant  change  was  replacement  of  the  appendix  combining  the 
Missile/Space  missions;  current  Air  Force  organization  b  better  reflected  by  the 
Mbsile  mbsion  (Appendix  D)  and  the  Space  mbsion  (Appendix  F). 

6.  SUMMARY  OF  TASK  5  -  METHODOLOGIES  FOR  C^I  SYS¬ 
TEMS 

In  thb  task,  the  guidelines  developed  in  Tasks  1,  2.  and  3  were  used  to  select 
software  requirements  and  software  design  methodologies  to  form  the  front-end 
of  an  environment  especially  designed  to  support  the  development  of  a  C^I  sys¬ 
tem.  Selected  toob,  especially  those  tnat  address  software  design  activities,  are 
required  to  be  compatible  with  the  Ada  Programming  Language. 

The  survey  of  C^I  systems  summarized  in  Appendix  C  of  the  guidebook,  and 
our  experience  with  a  variety  of  ground-based  and  airborne  C^I  systems,  con¬ 
vinced  us  that  we  couldn’t  fully  demonstrate  usage  for  thb  mission  with  a  sin¬ 
gle  example.  The  complexity  and  variety  of  the  many  C^I  systems,  requiring 
different  combinations  of  software  functions,  makes  it  difficult  for  a  single  set  of 
methodologies  to  suffice.  Therefore,  we  chose  two  C^I  systems  to  serve  as 
examples.  Additionally,  we  decided  to  demonstrate  use  of  all  three  selection 
paths. 

A  ground-based  interactive  display  system  b  used  to  demonstrate  Path  1,  which 
allows  choosing  a  methodology  based  on  the  needs  of  the  requirements  phase. 
An  air-borne  system  targeted  for  a  special  purpose  computer  b  used  to  demon¬ 
strate  Path  2,  which  allows  choosing  a  methodology  based  on  the  needs  of  the 
design  phase.  Our  third  example  demonstrates  how  an  experienced  project 
manager  can  select  a  methodology  based  on  specific  capabilities,  without 
referencing  the  actual  project  for  which  he  wants  that  methodology. 


7.  INSTRUCTIONS  FOR  MAINTENANCE  OF  GUIDEBOOK 
Since  the  guidelines  are  extensible,  it  is  possible  to  update  the  Guidebook  to: 
(a)  add  methodologies,  (b)  reflect  capability  enhancements  in  existing  metho¬ 
dologies,  (c)  change  (by  addition  or  deletion)  the  list  of  capabilities  against 
which  a  methodology  is  scored,  and  (d)  reflect  any  changes  in  the  relationships 
of  software  categories  to  desired  capabilities. 

Section  7.1  describes  how  to  compute  the  scores  for  a  methodology.  The  scores 
are  a  function  of  the  software  category,  the  path  (life  cycle  phase),  and  the 
significance  level  of  the  project.  (Scoring  a  methodology  generates  18*2*4=144 
values.)  Section  7.2  explains  what  changes  are  necessary  if  the  Ust  of  capabili¬ 
ties  rated  (presently  30)  is  expanded. 

7.1.  Scoring  s  Methodology 

The  process  described  below  shows  how  to  update  the  existing  scores  for  a  pre¬ 
viously  evaluated  methodology  or  to  add  scores  for  a  methodology  never  before 
evaluated.  An  update  would  become  necessary  when  a  revised  version  of  the 
methodology  or  its  tool  set  is  released.  A  methodology  can  be  added  as  infor¬ 
mation  becomes  available  for  rating  its  capabilities,  as  long  as  it  is  usable  by 
organizations  other  than  its  developers. 

Scoring  a  methodology  can  proceed  only  after  its  individual  capabilities  have 
been  rated.  Appendix  B  details  the  rating  system  on  which  the  present  score 
tables  are  based.  The  appendix  also  contains  a  table  (figure  B-1)  listing  capa¬ 
bility  ratings  for  the  methodologies  evaluated  in  the  Guidebook.  The  table  was 
used  to  compute  the  Path  1  and  2  scores  given  in  the  Guidebook;  and  is  identi¬ 
cal  to  Guidebook  figure  2-22.  This  figure  should  be  updated  if  the  ratings  for  a 
methodology  are  revised  or  if  a  new  methodology  is  rated. 

Figure  7-1  is  a  two  page  worksheet  that  organizes  the  calculations  for  a  single 
software  category.  Figure  7-2  is  a  completed  worksheet.  In  this  example,  the 
software  category  used  is  5  and  the  methodology  is  SREM.  Down  the  left  side 
of  the  first  page  of  the  worksheet  is  a  list  of  the  30  capabilities  used  to  rate 
methodologies.  The  next  column  RATING  has  space  for  listing  the  individual 
rating**  of  those  capabilities.  We  used  the  capabilities  ratings  shown  in  figure 
B-1  of  appendix  B  to  calculate  the  methodology  scores  used  in  the  guidebook. 

The  third  column  DESIRED  has  space  for  marking  the  capabilities  which  are 
desired  for  the  software  category.  The  capabilities  are  divided  into  three 
groups;  requirements,  design,  and  universal.  Notice  that  the  DESIRED  column 
is  already  marked  for  the  universal  capabilities  group.  The  scoring  process 
assumes  that  all  universal  capabilities  are  desirable.  Figure  7-3  is  a  matrix  of 
requirements  capabilities  versus  software  category  with  z’s  marking  the  desired 
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Methodology  Scoring  Worksheet  -  pnge  2 


Software  Category _ Methodology 


SUM(1)  =  SUM(R)  +  SUM(D)  +  SUM(U)  = 

SUM{2)  =  SUM(D)  +  SUM(U)  = 

COUNT(l)  =  COUNT(R)  +  COUNT(D)  +  COUNT(U)  = 
COUNT(2)  =  COUNT(D)  +  COUNT(U)  = 

PATHl 


OSL=0:  MS(1,0)  =  SUM(1)  = 

OSL=l:  MS(1,1)  =  SUM(l)  -  COUNT(l)  = 
0SL=2:  MS(1,2)  =  SUM(1)  -  2*COUNT(l)  = 
OSL=3:  MS(1,3)  =  SUM(1)  -  3*C0UNT(1)  = 

PATH  2 


OSL=0:  MS(2,0)  =  SUM(2)  = 

OSL=l;  MS(2,1)  =  SUM(2)  -  COUNT(2)  = 
0SL=2;  MS(2,2)  =  SUM(2)  -  2*COUNT(2)  = 
OSL=3:  MS(2,3)  =  SUM(2)  -  3»COUNT<2)  = 


rigure  7-1:  Methodology  Scoring  Worksheet  (part  2  of  2) 


Software  Category . 


Methodology  Seoring  Worksheet  •  page  1 
.  Methodology  _ 


METHODOLOGY  SCORING  WORKSHEET  -  page  S 
Software  Category  ^  Methodology  SREH _ 

SUM(1)  =  SUM(R)  +  SUM(D)  +  SUM(U)  ==  = 

SUM(2)  =  SUM(D)  +  SUM(U)  =  »  V<? 

COUNT(l)  =  COUNT(R)  +  COUNT(D)  +  COUNT(U)  =  S-hJ  ^  /O 
COUNT(2)  =  COUNT(D)  +  COUNT(U)  =  ^  4-  J  6  ^ 

PATH  I 

OSL«0;  MS(1,0)  =  SUM(1)  =  ‘f? 

OSL=l:  MS{1,1)  =  SUMCl)  -  COUNT(l)  = 

OSL==2:  MS(1,2)  =  SUM(1) -  2*COUNT(l)  =V-7-4.Jf-;j/»  -/ 
OSL=3:  MS(1,3)  =  SUM(1)  -  3*COUNT(l)  =  ^  ^ 

PATH  2 

OSL=0:  MS(2,0)  =  SUM(2)  =  ^<9 

OSL==l:  MS(2,1)  =  SUM(2)  -  COUNT(2)  =  <^0  -  J  9 

OSL=2:  MS(2,2)  =  SUM{2)  -  2»COUNT(2)  =  --  ^4-  l<f 

OSL=3:  MS(2,3)  =  SUM(2)  -  3*COUNT(2)  =  ifo-  3*-!  9  =  - /' 

Figure  7-2:  Example  Use  of  Methodology  Scoring  Worksheet 

(part  2  of  2) 
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entries.  Figure  7-4  is  a  matrix  of  design  capabilities  versus  software  category 
with  *’s  marking  the  desired  entries.  Across  the  software  category  row,  the 
capability  entries  marked  as  desired  in  figures  7-3  and  7-4  are  exactly  those 
capabilities  to  be  marked  in  the  DESIRED  column  on  the  worksheet.  The  set 
of  desired  capabilities  describes  the  ideal  methodology  for  the  software  category. 

The  fourth  column  VALUE  has  space  for  recording  the  ratings  of  the  capabili¬ 
ties  marked  as  desired.  Undesirable  capabilities  are  given  a  value  of  zero. 

The  last  column  on  the  first  page  has  space  for  recording  intermediate  "alues. 
For  each  group  of  capabilities  it  is  necessary  to  count  the  number  of  desired 
capabilities  (note  that  the  count  for  the  universal  group  is  pre-printed)  and  sum 
the  numbers  in  the  VALUE  column.  The  definitions  for  the  each  group  are 
listed  below. 


The  second  page  of  the  worksheet  has  the  formulas  for  computing  the  scores. 
The  four  formulas  labeled  COUNT(l),  COUNT(2),  SUM(l),  and  SUM(2)  are 
intermediate  values.  (The  number  inside  the  parentheses  indicates  the  path 
number,  corresponding  to  Paths  1  or  2  in  the  Guidebook.  Since  the  success  of 
Path  3  depends  on  the  expertise  of  a  user,  any  methodology  scoring  for  Path  3 
will  derive  from  the  user’s  own  formula.) 


COUNT(R) 

r  amber  of  requirements 

capabilities  marked  as 

desired 

..  •  -  .  h”-  a..  ^ 

SUM(R) 

sum  of  values  in  require¬ 

ments  capabilities  group 

•  *  “  *  *  .  •  • 

•.*  '  *  ' 

COUNT(D) 

number  of  design  capabili¬ 

ties  marked  as  desired 

SUM(D) 

sum  of  values  in  design 

*'  -*  .■*  .'••'a"'. 

capabilities  group 

COUNT(U) 

number  of  universal  capa¬ 

bilities  marked  as  desired 

SUM(U) 

sum  of  values  in  universal 

.'I 

capabilities  group 

■  A 


'-[im  »'J-  ‘'■*'  '!^- ' 
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The  general  formula  for  computing  the  Methodology  Score  (MS)  for  a  particular 
path  and  significance  level  is: 

MS(path,  si)  =  SUM(path)  -  si  *  COUNT(path). 

The  first  term  of  the  formula  [SUM(path)]  is  the  support  power  the  methodol- 
ogy  provides.  The  second  term  [si  ♦  COUNT{path))  is  the  support  power  an 
ideal  methodology  would  provide  at  a  given  significance  level  with  a  uniform  ^ 
rating  (the  specific  si)  per  capability.  Thus,  the  second  term  serves  as  a  correc¬ 
tion  factor.®  The  MS  value  represents  the  support  power  of  the  methodology 
relative  to  the  support  power  of  the  ideal  methodology.  A  positive  result  indi¬ 
cates  that  the  selected  methodology  provides  more  support  to  the  specification 
process  than  nominally  desired.  A  negative  result  indicates  less  support  than 
nominally  desired. 

The  remaining  8  formulas  on  the  page  are  resolutions  of  the  general  formula  for 
Path  1  (the  requirements  phase  path),  Path  2  (the  design  phase  path),  and 
significance  levels  0  through  3.  The  Methodology  Score  (MS)  computation  for 
both  paths  includes  all  the  universal  capabilities  since  they  will  be  desirable  in 
both  requirements  and  design  specification  phases.  The  MS  computation  for 
Path  1  includes  requirements  and  design  capabilities  since  it  chooses  a  metho¬ 
dology  that  will  be  used  beginning  in  the  requirements  phase  and  continuing 
through  the  design  phase.  The  MS  computation  for  Path  2  excludes  the 
requirements  capabilities  smce  the  selected  methodology  will  be  used  beginning 

7.  The  foroiula  for  computing  the  Methodologjr  Score  (MS)  if  the  capabilities  desired  in 
the  ideal  methodology  are  treated  non-uniformly  is: 

=  S  ('■«««»*•*/♦»  “  ) 

«tt  itilfti  ccpakUthti 

where  is  the  methodology's  rating  for  a  particular  capability  and  r,^,^  is  the 

rating  given  that  capability  in  the  ideal  methodology.  Note  that  the  MS  sum  only  in¬ 
cludes  the  capabilities  desired  in  the  ideal.  Thus,  methodologies  are  not  penalized  for 
providing  capabilities  other  than  those  nominally  desired,  which  is  reasonable  since  un¬ 
desired  capabilities  can  be  ignored. 

8.  Notice  that  the  correction  factor  for  signiflcance  level  0  is  0.  This  corresponds  to  the 
realistic  assumption  that  development  of  a  project  with  the  following  characteristics  does 
not  need  specification  technology:  (a)  Low,  tight  budget,  (b)  no  criticality  assignment,  (c) 
tight  schedule,  (d)  straight-forward  solution  and  easy  to  check  out,  (e)  few  formal  require¬ 
ments,  (f)  expected  use  in  a  local  environment  as  test  or  demonstration  software,  (g)  not 
required  to  recover  from  anomalous  conditions,  (h)  acceptance  predicated  solely  on  correct 
functionality,  (i)  not  expected  to  be  maintained,  and  (j)  documentation  confined  to  source 
code. 


32 


in  the  design  phase. 


The  results  for  path  1  are  used  to  update  Guidebook  figures  2-9  through  2-12 
(for  significance  level  0  through  3  respectively).  The  results  for  path  2  are  used 
to  update  Guidebook  figures  2-17  through  2-20  (for  significance  level  0  through 
3  respectively).  The  columns  of  the  figures  represent  software  categories;  the 
rows  of  the  figures  represent  methodologies.  Updating  a  methodology’s  scores  is 
a  matter  of  locating  the  proper  row  and  column  and  modifying  the  value.  Fig¬ 
ure  7-5  locates  the  proper  entry  for  updating  the  OSL  value  of  2  for  path  1, 
software  category  5  and  methodology  F  (SREM).  Adding  a  methodology  is  a 
matter  of  adding  a  new  row,  and  entering  values  in  the  proper  columns  for  the 
each  software  category. 

7.2.  Expansion  of  the  Capabilities  List 

If  a  capability  is  added  to  the  capability  list,  it  will  be  necessary  to  recompute 
the  scores  for  every  methodology  with  respect  to  each  software  category  in 
which  that  capability  is  desired.  If  the  capability  belongs  to  the  universal  group, 
it  will  be  necessary  to  recompute  scores  for  every  methodology  and  every 
software  category.  If  the  capability  belongs  to  the  requirements  group,  it  will 
only  be  necessary  to  recompute  Path  1  scores.  If  the  capability  belongs  to  the 
design  or  universal  group,  it  will  be  necessary  to  recompute  both  Path  1  and  2 
scores. 

The  steps  for  adding  a  capability  follow: 

(1)  Define  the  capability. 

(2)  Define  the  significance  level  ratings  for  the  capability.  (The  rat¬ 
ings  used  in  the  guidebook  are  defined  in  Appendix  B.) 

(3)  Decide  the  group  (requirements,  design,  or  universal)  to  which  the 
capability  belongs.  That  is,  is  the  utility  of  the  capability  independent 
of  life  cycle  phase?  If  so,  then  it  belongs  to  the  universal  group.  If 
not,  then  in  which  phase  is  it  useful? 

(4)  If  the  group  is  requirements  or  design,  update  the  appropriate 
desirability  matrix  (figure  7-2  or  7-3)  to  show  the  desirability  of  the 
capability  relative  to  the  18  software  categories. 

(5)  Rate  the  methodologies  for  that  capability,  adding  the  ratings  to 
Guidebook  figure  2-22. 

(6)  For  every  methodology  recompute  the  significance  level  scores  for 
the  paths  and  software  categories  impacted  by  the  addition  of  the 
capability. 


8.  RECOMMENDATIONS 

We  recommend  that  the  methodology  used  in  the  Guidebook  be  computerized, 
so  that  a  user-friendly  interface  (perhaps  menu-driven)  would  lead  the  user 
step-by-step  through  the  selection  procedure.  The  software  could  be  pro¬ 
grammed  to  perform  all  computations  and  pattern  matching  now  required  of 
the  user.  The  Guidebook  selection  method  has  been  designed  in  a  modular 
fashion  so  that  tables  can  be  easily  changed  to  reflect  advances  in  the  technol¬ 
ogy,  and  easily  expanded  to  include  new  methodologies  and  techniques.  This 
same  structure  could  be  implemented  on  a  computer,  permitting  the  same 
growth  and  flexibility  as  the  Guidebook.  Further,  the  ability  of  a  menu-driven 
scheme  to  vary  its  actual  presentations  based  on  the  software  category  involved 
would  make  it  feasible  to  include  more  quality  attributes  in  the  significance 
level  computations. 

Our  second  recommendation  is  to  re-evaluate  the  18  standard  software 
categories  after  several  years  of  use.  By  that  time,  any  significant  problems 
should  be  evident,  either  in  the  categories  themselves  or  in  clarity  of  definitions. 
Usage  in  the  field  often  uncovers  difficulties  unforeseen  by  the  designers;  and 
software  engineers  often  have  different  vantage  points  for  viewing  the  world  of 
software.  During  our  investigation,  we  found  no  compelling  reason  to  modify 
the  categories,  which  were  derived  as  part  of  another  contract  to  build  a 
Software  Test  Handbook  (RADC-TR-84-53,  Vol.  II)  for  the  Air  Force. 

Our  third  recommendation  is  that  consideration  be  given  to  a  study  that  rates 
the  effectiveness  of  usage  of  the  Guidebook  selections.  Appropriate  questions 
might  be: 

(a)  Was  the  methodology  a  success?  (Remember  our  survey  did  not 
uncover  any  successes.) 

(b)  What  capabilities  would  have  been  helpful,  but  were  not  provided? 
(Should  the  list  of  capabilities  be  expanded?) 

(c)  What  capabilities  were  not  used?  (Should  the  recommended  capa¬ 
bilities  for  a  particular  software  category  be  adjusted?) 

(d)  Did  any  capability  have  a  negative  impact  on  meeting  project 
goab  such  as  cost  or  schedule?  (Does  the  significance  level  determina¬ 
tion  need  adjustment?) 
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A.l  Methodology  Description  Format 


General  Aspects 

A.  Identification 

Gives  the  name  and  acronym  of  the  methodology  and  identifies 
the  deveioping/supporting  organization. 

B.  Overview 

Contains  a  short  description  of  the  salient  features  of  the  metho¬ 
dology. 

C.  Identifies  the  specification  life  cycle  phases  supported: 

Requirements  Analysis,  Architectural  Design  (intermodule  com¬ 
munication,  data  structures),  or  Detailed  Design  (module  func¬ 
tionality). 

Complementary  methodologies  will  be  listed  for  phases  not  sup¬ 
ported. 


D.  Software  Categories 


Lists  standard  software  categories  which  are  compatible  with  this 
methodology. 


a 

Category 

IB 

Category 

I 

Arithmetic-based 

2 

Event  Control 

3 

Process  Control 

IB 

Procedure  Control 

5 

Navigation 

IB 

Flight  Dynamics 

IB 

Orbital  Dynamics 

8 

Message  Processing 

IB 

Diagnostic  S/W 

10 

Sensor/signal  Processing 

11 

Simulation 

12 

Database  Management 

13 

Data  acquisition 

14 

Decision/planning  aids 

15 

Data  presentation 

18 

Pattern/image  processing 

17 

Computer  System  Software 

18 

S/W  development  tools 

E.  Suitable  for  systems  of  size: 

—  Small  (<2,000  lines  of  code) 

—  Medium  (2,000  -  10,000  lines  of  code) 

—  Large  (>10,000  lines  of  code) 

Technical  Aspects 
A.  Primary  approach 

For  a  requirements  methodology,  the  approaches  are: 

—  flow-oriented, 

—  object-oriented,  and 

—  state-oriented. 
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For  a  design  methodology,  the  approaches  are: 


—  data-structured, 

—  decompositicQ, 

—  encapsulation,  and 

—  programming  calculus. 

B.  Supports 

Traceability _ 

Functional  hierarchy /decomposition 
Data  hierarchy /data  abstraction 

Interface  definition _ 

Database  definition _ 

Data  flow _ 

Sequential  control  flow _ 

Concurrency /parallelism _ 

Formal  program  verification _ 

Iterative  development _ 


C.  Workproducts 

Are  they  relevant  to  MIL-STD  documentation? 
a.  Textual 

Descriptions  of  reports,  documents  produced. 
h.  Graphical 

Descriptions  of  diagrams  produced. 

D.  Performance  Specification 


Does  the  methodology  have  the  capability  to  specify  or  test  tim¬ 
ing  and/or  accuracy  constraints  that  apply  to  individual  system 
functions? 


E.  Operating  Qualities  Specification 


Does  the  methodology  have  the  capability  to  specify  the  following 
constraints? 

—  Man/machine  interaction 

—  Fault-tolerance 


—  Portability 

—  Reusability 

—  Security 


F.  Ada  compatibility 


Ada  Feature  Supported 

Packages 

Tasks 

Generics 

Exception  Handling 

Types 

Representations 

X  indicates  suppori 
C  indicates  conflict 

of  feature, 
with  feature. 

G.  Quality  Assurance 

How  does  the  methodology  check  or  enforce: 

—  Consistency  ? 

—  Completeness  ? 

—  Validation  ? 

H.  Independent  of 

Are  the  resulting  specifications  independent  of: 


—  Implementation  Language  ? 

—  Hardware  Architecture  ? 


—  Operating  System  Architecture  ? 

3.  Support  Aspects 

..4.  Automated  Tools 

Describes  which  automated  tools  are  available. 

B.  Language 

Identifies  the  language  used  in  the  following  specification  phases 
and  its  degree  of  formality. 

—  Requirements  Specification 

—  Architectural  Design 

—  Detailed  Design 

4.  Management  Aspects 

Does  the  methodology  support  project,  technical,  or  configuration 
management?  How? 

5.  Usage  Aspects 

A.  Equipment/ Facilities  Needed  to  use 

Identify  specific  hardware  and  software  (operating  systems,  graph¬ 
ics  packages)  required  to  use  the  methodology  or  associated 
automated  tools. 


B.  Usability 


Methodoloe 


Level _ 

Easy  to  Use _ 

Moderately  Easy  to  Use 
Moderately  Difficult  to  Use 
Difficult  to  Use 


C.  Extent  of  Use 

fa  the  methodology  mature?  Has  it  been  used  outside  the  develop¬ 
ing  organization?  How  much? 

Transferability 

A.  Availability 

fa  the  methodology  in  the  public  domain,  commercially  available, 
etc.? 

B.  Training  Available 

—  Public  documentation 
—  Proprietary  documentation 


—  Consultants 

—  Seminars  -  scheduling  and  cost,  if  known 
Trainina  and  Experience  Reauired 


Trainine/Experience  Needed 


months 


The  table  entries  reflect  the  amount  of  training  and  expenence 
time  required  to  use  the  methodology  effectively.  A  USER  is  an 
individual  who  develops  or  assists  in  developing  requirements 
and/or  design  specifications.  An  ORGANIZATION  is  a  group  of 
users  developing  specifications  as  a  team. 


A.2  Tool  Set  Description  Format 
1.  General  Aspects 

A.  Identification 

Gives  the  name  and  acronym  of  the  tool  or  tool  set  and  identifies 
the  developing/supporting  organization. 

B.  Methodologies 

Lists  what  methodology  the  tool  set  supports. 

C.  Life  cycle  phases  supported: 

Identifies  which  of  the  specification  phases  the  tool  set  supports; 

—  requirements  analysis 

—  architectural  design  (intermodule  communication,  data  struc¬ 
tures) 

—  detailed  design  (module  functionality) 


D.  Software  Categories 


Lists  standard  software  categories  which  are  compatible  with  this 
methodology. 


# 

Category 

# 

Category 

1 

Arithmetic-baaed 

2 

Event  Control 

3 

Proeeaa  Control 

B 

Procedure  Control 

5 

Navigation 

B 

Flight  Dynamics 

m 

Orbital  Dynamics 

8 

Message  Processing 

B 

Diagnostic  S/W 

10 

Sensor/signal  Processing 

11 

Simulation 

12 

Database  Management 

13 

Data  acquisition 

14 

Decision/planning  aids 

15 

Data  presentation 

16 

Pattern/image  processing 

17 

Computer  System  Software 

18 

S/W  development  tools 

E.  Suitable  for  systems  of  size: 

—  Small  (<2,000  lines  of  code)  ? 

—  Medium  (2,000  -  10,000  lines  of  code)  ? 
—  Large  (>10,000  lines  of  code)  ? 
Technical  Aspects 
A.  Supports 
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Traceability _ 

Functional  hierarchy /decomposition 
Data  hierarchy /data  abstraction 

Interface  definition _ 

Database  definition _ 

Data  flow _ 

Sequential  control  flow _ 

Concurrency  /parallelbm _ 

Formal  program  verification _ 

Iterative  development _ 


B.  Workproducts 

Are  they  relevant  to  MIL-STD  documentation? 

а.  Textual 

Description  of  reports,  documents  produced. 

б.  Graphical 

Description  of  diagrams  produced. 

C.  Performance  Specification 

Does  the  tool  set  have  the  capability  to  specify  or  test  timing 
and/or  accuracy  constraints  that  apply  to  individual  system  func¬ 
tions? 

D.  Operating  Qualities  Specification 

Does  the  tool  set  have  the  capability  to  specify  the  following  con¬ 
straints? 

—  Man/machine  interaction 


—  Fault-tolerance 


—  Portability 

—  Reusability 

—  Security 


E.  Ada  eompatibili 


Ada  Feature  Supported 

Packages 

Tasks 

Generics 

Exception  Handling 

Tines 

Renresentations 

X  indicates  support  of  the  feature. 

C  indicates  conflict  with  the  feature. 

F.  Quality  Assurance 

How  does  the  tool  set  support 

a.  Consistency  checking  ? 

b.  Completeness  checking  ? 

c.  Validation  ?  by  a  manual  or  computer-processed  procedure  ? 

d.  Rapid  prototyping  ? 

Does  it  prototype  the  man-machine  interface?  the  software 
modularization  scheme?  the  functionality  of  the  system?  is 
the  execution  mode  of  the  prototype  a  simulation  or  a  sym¬ 
bolic  execution?  Is  the  prototype  suitable  for  pre-release? 

e.  Performance  validation  ?  of  correctness  or  eSiciency? 


3.  Support  Aspects 


A.  Degree  of  Integration 


Vertical  -  within  one  phase  of  the  software  life  cycle?  Or  horizon¬ 
tal  -  across  more  than  one  phase  of  the  software  life  cycle? 

B.  Language 

Identifies  language(s)  used  for  specification  phases  and  its  degree 
of  formality. 

—  Requirements  Specification 
—  Architectural  Design 
—  Detailed  Design 

4.  Management  Aspects 

Does  the  tool  set  support  project,  technical,  or  configuration  manage¬ 
ment?  How? 

5.  Usage  Aspects 

A.  Equipment/ Faeilitiea  Needed  to  use 

Identify  specific  hardware  and  software  (operating  systems,  graph¬ 
ics  packages)  required  to  use  the  tool  set  or  associated  automated 
tools. 

B.  Usability  _ 


Level 

Methodology 

Easy  to  Use 

Moderately  Easy  to  Use 

Moderately  Difficult  to  Use 

Difficult  to  Use 

C.  Extent  of  Use 

Has  the  tool  set  been  used  outside  the  developing  c  rganization? 
How  much? 


6.  Transferability 

A.  Availability 


Is  the  tool  set  in  the  public  domain,  commercially  available,  etc.? 

B.  Training  Available 

—  Public  documentation 
—  Proprietary  documentation 
—  Consultants 

—  Seminars  -  scheduling  and  cost,  if  known 

C.  Training  and  Experience  Required 


TraininR/Experience  Needed 

months 

USER 

MANAGER 

ORGANIZATION 

<  1 

\mm\ 

wmmm 

1  -  3 

\^m 

3-6 

IHHI 

{■■■■I 

>  6 

The  table  entries  reflect  the  amount  of  training  and  experience 
time  required  to  use  the  tool  set  effectively.  A  USER  is  an  indivi¬ 
dual  who  develops  or  assists  in  developing  requirements  and/or 
design  specifications.  An  ORGANIZATION  is  a  group  of  users 
developing  specifications  as  a  team. 


Interpretations  of  Capability  Ratings 

Scale  runs  from  1  to  3,  with  3  indicating  best  support  and  1  indicating  least. 

STATE  MODELING  -  Representation  in  diagrammatic  form  of  the  system 
state  and  transformations  to  the  state  resulting  from  inputs  or  other  stimuli. 

3  Use  of  transition  diagrams  as  primary  technique  for  description  of 
requirements. 

2  Use  of  transition  diagrams  as  secondary  technique. 

1  State  indirectly  encapsulated  by  an  abstraction  (process  or  data). 

DATA  FLOW  MODELING  -  Representation  of  the  flow  of  information  objects 
between  various  processing  elements  and/or  storage  elements. 

3  Use  of  data  flow  diagrams  as  primary  technique  for  description  of 
requirements. 

2  Use  of  data  flow  diagrams  as  secondary  technique. 

1  Inputs/outputs  indicated  on  diagrams. 

CONTROL  FLOW  MODELING  -  Representation  of  the  sequence  in  which  pro¬ 
cessing  will  take  place. 

3  Use  of  control  flow  diagrams  as  primary  technique  for  description  of 
requirements. 

2  Use  of  control  flow  diagrams  as  secondary  technique. 

1  Flow  of  control  implied  in  diagram  (such  as  transition  diagrams). 

OBJECT  MODELING  -  Representation  of  data  or  processes  as  independent 
objects  with  their  own  state  information  and  capacity  to  change. 

3  Use  of  process  or  data  abstractions  as  primary  technique  for  descrip¬ 
tion  of  requirements. 

2  Use  of  process  or  data  abstractions  as  secondary  technique. 

1  Use  of  Entity-Relationship  diagrams  as  secondary  technique  for 
modeling  software  system. 

TIMING  SPECIFICATION  -  Statement  of  the  timing  constraint  for  a  particu¬ 
lar  processing  step. 

3  Have  capability  to  formally  specify  and  measure  timing  constraints. 

2  Have  capability  to  formally  specify  but  not  measure  timing  con¬ 
straints. 


1  Can  associate  timing  constraint  with  a  processing  step  as  a  com¬ 
ment  added  to  a  diagram  or  textual  specification. 

ACCURACY  SPECIFICATION  -  Statement  of  the  accuracy  constraint  for  a 
particular  processing  step. 

3  Have  capability  to  formally  specify  and  measure  accuracy  con¬ 
straints. 

2  Have  capability  to  formally  specify  but  not  measure  accuracy  con¬ 
straints. 

1  Can  associate  accuracy  constraint  with  a  processing  step  as  a  com¬ 
ment  added  to  a  diagram  or  textual  specification. 

FUNCTIONAL  DECOMPOSITION  -  A  function  at  one  level  is  actually  com¬ 
posed  of  several  interconnected  functions  that  exist  as  a  level  of  greater  detail. 

3  Primary  mechanism  for  design  structuring  is  functional  decomposi¬ 
tion. 

2  Secondary  mechanism  for  design  structuring  is  functional  decompo¬ 
sition. 

1  Structure  charts  of  design  drawn. 

DATA  DECOMPOSITION  -  A  set  of  data  at  one  level  is  actually  composed  of 
several  interconnected  pieces  of  data  that  exist  as  a  level  of  greater  detail. 

3  Primary  mechanism  for  design  structuring  data  decomposition. 

2  Secondary  mechanism  for  design  structuring  is  data  decomposition. 

1  Data  dictionary  is  maintained. 

CONTROL  DECOMPOSITION  -  The  flow  of  control  at  one  level  is  actually 
composed  of  several  interconnected  control  flows  that  exist  as  a  level  of  greater 
detail. 

3  Primary  mechanism  for  design  structuring  is  control  decomposition. 

2  Secondary  mechanism  for  design  structuring  is  control  decomposi¬ 
tion. 

1  Calling  tree  is  maintained. 

DATA  ABSTRACTION  -  The  concept  of  hiding  information  about  the  imple¬ 
mentation  of  a  data  object  and  providing  a  set  of  implementation-independent 


functions  for  use  of  the  data  object. 

3  Primary  mechanism  for  design  structuring  is  data  abstraction. 

2  Secondary  mechanism  for  design  structuring  is  data  abstraction. 

1  Principle  of  information  hiding  is  one  consideration  during  design. 

PROCESS  ABSTRACTION  -  The  concept  of  hiding  information  about  the 
implementation  of  a  process  object  and  providing  a  set  of  implementation- 
independent  functions  for  use  of  the  process  object. 

3  Primary  mechanism  for  design  structurmg  is  process  abstraction. 

2  Secondary  mechanism  for  design  structuring  is  process  abstraction. 

1  Principle  of  information  hiding  is  one  consideration  during  design. 

DATABASE  DEFINITION  -  The  process  of  defining  the  data  objects  and  their 
relationships  as  a  data  model  or  semantic  hierarchy. 

3  A  database  design  per  $e  is  one  part  of  the  design  process. 

2  Data  objects  are  defined  as  abstract  data  types. 

1  The  valid  ranges  and  formats  for  data  objects  arc  defined. 

CONCURRENCY/SYNCHRONICITY  -  Processing  can  be  defined  as  separate 
sequential  streams  concurrently  in  execution. 

3  Concurrent  sequential  cooperating  processes  with  explicit  synchroni¬ 
zation  specified. 

2  Concurrent  sequential  cooperating  processes  without  explicit  syn¬ 
chronization  specified. 

1  Specification  of  concurrency  within  a  code  unit. 

MODULE  INTERFACE  SPECIFICATION  -  The  concept  of  having  distinct 
and  well-defined  boundaries  between  processes  or  sets  of  data.  The  inputs,  out¬ 
puts,  calling  mechanism,  and  pre-conditions  for  use  can  be  specified. 

3  Specify  inputs,  outputs,  mechanism,  and  pre-conditions  with  a  for¬ 
mal  notation.  Consistency  checks  computer-processed. 

2  Specify  inputs,  outputs,  and  mechanism  with  a  formal  notation. 
Consistency  checks  computer-processed. 

1  Specify  inputs,  outputs,  and  mechanism  with  an  informal  notation. 
Consistency  checks  manually-processed. 
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FORMAL  VERIFICATION  -  The  process  of  proving  that  the  formalization  of 
the  processing  abstraction  exhibits  the  desired  behavior. 

3  A  theorem  prover  is  provided  to  assist  the  verification  process. 

2  The  specification  is  formal,  and  can  be  verified  manually. 

1  Justification  is  provided  as  narrative  text. 

CONFIGURATION  MANAGEMENT  -  The  way  in  which  the  methodology 
and/or  its  tools  provides  for  organization,  tracking,  and  maintenance  of  the 
emerging  workproducts,  including  control  of  releases  and  multiple  versions. 

3  Automated  support  for  organization,  tracking,  and  maintenance  of 
workproducts. 

2  Partial  automated  support  for  organization,  tracking,  and  mainte¬ 
nance  of  workproducts. 

1  Version  control  alone  is  provided. 


COMPLETENESS  ANALYSIS 

3  Computer-assistance  for  completeness  analysis  provided,  syntax  and 
simulated  or  symbolic  execution  (flow  analysis)  are  checked. 

2  Computer-assistance  for  syntax  checks. 

1  Completeness  checked  by  manual  procedures  (author/reader;  walk¬ 
throughs). 


... 


CONSISTENCY  ANALYSIS 

3  Computer-assistance  for  consistency  analysis  provided,  syntax  and 
simulated  or  symbolic  execution  (flow  analysis)  are  checked. 

2  Computer-assistance  for  syntax  checks. 

1  Consistency  checked  by  manual  procedures  (author/reader;  walk¬ 
throughs). 


y-'.'-vA'.-.--’. 


ADA  COMPATIBILITY  -  The  methodology  can  produce  a  design  that  can  be 
implemented  in  ADA,  making  use  of  its  principal  features. 

3  All  of  the  principal  features  (packages,  tasks,  generics,  exception 
handling,  types,  and  representations)  can  be  utilized. 

2  Some  of  the  principal  features  (packages,  tasks,  generics,  exception 
handling,  types,  and  representations)  can  be  utilized.  There  are  not 
any  conflicts  between  Ada  features  and  the  methodology. 


/  / 


1  Some  of  the  principal  features  (packages,  tasks,  generics,  exception 
handling,  types,  and  representations)  can  be  utilized.  There  are 
conflicts  between  the  methodoloy  and  and  at  least  one  Ada  feature 
and  some  other  incompatibilities  may  exist. 

CODE  BEHAVIOR  NOTATION  -  The  notation  used  for  describing  the  internal 
logic  or  behavior  of  a  unit  of  code. 

3  The  syntax  of  the  notation  is  formal  and  can  be  checked  by  a  com¬ 
puter  process.  (Pseudocode  pdl  or  formal  graphic  pdl). 

2  The  behavior  is  specified  with  a  structured  or  rigourous  natural 
language  (English)  which  may  include  control  constructs  such  as  do  ... 
while... 

1  The  behavior  is  specified  with  totally  free  natural  language 
(English). 


, 


PROTOTYPING  -  Simulating  the  behavior  of  a  system  by  symbolic  or  simu¬ 
lated  execution. 

3  The  simulation  provides  sufficient  functionality  and  efficiency  to  be 
used  as  a  pre-release. 

2  The  simulation  mimics  all  the  functionality  of  the  system. 

1  The  simulation  mimics  part  of  the  functionality  of  the  system,  such 
as  report  formats  or  interactive  dialogue. 

TEST  PLAN  GENERATION  -  Formulation  of  a  plan  and  a  series  of  tests  to 
validate  the  functionality  and  efficiency  of  the  implemented  system. 

3  Automated  support  for  test  plan  generation  is  provided. 

2  Manual  procedures  and  guidelines  for  test  plan  generation  are  pro¬ 
vided. 

1  The  methodology  recommends  that  test  plans  be  formulated. 


AUTOMATED  TOOLS  AVAILABLE 

3  The  automated  tools  support  the  entire  methodology  process. 

2  (Not  Defined.) 

1  The  automated  tools  support  part  of  the  process. 

TRACEABILITY  -  The  ability  to  trace  requirements  through  to  design  ele¬ 
ments  realizing  them. 
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3  Automated  support/enforcement  for  traceability  is  provided. 

2  Manual  procedures  for  traceability  are  provided. 

1  Manual  traces  are  possible. 

TRANSITION  BETWEEN  PHASES 

3  A  computer-processable  project  database  is  available. 

2  A  data  dictionary  b  maintained. 

1  The  methodology  spans  more  than  one  phase  of  the  software  lifecy¬ 
cle. 

VALIDATION  -  The  process  of  verifying  that  the  abstract  representation  of  the 
system  (requirements  specification,  design  specification)  does  provide  all  the  sys¬ 
tem  functionality  in  the  form  desired  by  the  customer. 

3  Some  form  of  simulated  execution  (aymbolii:  or  simulation)  of  the 
system  is  possible. 

2  Structured  walkthroughs  are  performed,  possibly  with  the 
customer/user. 

1  An  author/reader  cycle  for  specifications  is  followed. 

USABILITY  -  Ease  of  use. 

3  Easy  to  use. 

2  Moderately  easy  to  use. 

1  Moderately  difficult  to  use. 

MATURITY  -  Extent  of  use  of  the  methodology. 

3  In  use  outside  the  developing  organization  more  than  five  years. 

2  In  use  outside  the  developing  organization  less  than  five  years. 

1  Methodology  is  still  evolving. 

TRAINING/EXPERIENCE  LEVEL  -  Measure  of  how  much  experience  and 
training  is  needed  before  a  person  or  project  team  uses  a  methodology 
effectively. 

3  Less  than  one  month. 

2  One  to  three  months. 


1  More  than  three  months. 


MIL-STD  DOCUMENTATION  -  Conformance  to  military  documentation  stan 
dards  (MIL-STD-SDS). 

3  Directly  generate  documentation  in  MIL-STD  SDS  form. 

2  Workproducts  produced  follow  spirit  although  not  strict  form  of 
MIL-STD  SDS  documentation. 

1  Can  generate  documentation  in  MIL-STD  SDS  form  from  workpro¬ 
ducts  produced  by  methodology. 


TABLE  OF  METHODOLOGY  RATINGS 


Capability 

Methodology 

noBooDoonaaD 

REQUIREMENTS 

state  modeling 

o 

1 

B 

B 

1 

B 

1 

1 

n 

B 

B 

B 

data  Sow  modeling 

B 

B 

B 

B 

B 

1 

B 

B 

n 

B 

B 

m 

control  Sow  modeling 

Bi 

B 

B 

B 

B 

1 

D 

B 

B 

B 

B 

B 

object  modeling 

n 
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B 

1 
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3 

3 

3 

B 

B 
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B 

B 

1 

1 

1 

B 

B 

B 

o 

B 

B 

B 
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B 

1 

B 

1 

B 
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B 
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1 
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B 
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Figure  B-1:  Methodology  Capabilities  Ratings 


Attachment  2 


Changes  to  Draft  of  Specification  Technology  Final  Report 

-  per  phone  conference  on  May  3,1085 

-  and  phone  conference  on  May  6,1085 


Location _ 

Sec  1.1,  para  2 


sec  1.2,  para  2 


sec  1.2,  para  4 


sec  1.2,  para  7 


Change/CommeDt 
Replace  last  sen¬ 
tence  and  footnote 
with  ‘This  situation 
has  been  further 
complicated  with 
the  introduction  of 
the  Ada  program¬ 
ming  language. 
Users  must  under¬ 
stand  which  of  the 
methods  and  tech¬ 
niques  result  in 
designs  that  take 
maximum  advan¬ 
tage  of  the  softw  le 
engineering  princi¬ 
ples  which  Ada 
directly  supports 
and  implements’. 

insert  ‘of  the  guide¬ 
book’  after  ‘A 
through  F’. 

R*  move  typo  ‘a’ 
from  before  ‘metho¬ 
dologies’  in  1st  sen¬ 
tence 

Clarify  meaning  of 
data  base  manage¬ 
ment.  Possibly 
change  ‘Capabili¬ 
ties’  to  ‘Fftturf-s’ 
or  ‘Facilities 


V" '  \r.  9^ 


No. 

Location 

Change/Comment 

5 

figure  1-1 

Make  figure  con¬ 
sistent  with  text  in 
sec  1.4,  2nd  para 
items  a-e. 

6 

sec  1.4,  para  2 

Remove  typo  of  ‘to’ 
in  item  e. 

7 

sec  1.4,  para  8 

Add  ‘which  direct 
the  use  of 
specification  tech¬ 
nologies  in  the 
development  of  Air 
Force  systems’  to 
end  of  sentence. 

8 

sec  1.4,  para  9 

Add  ‘(figure  1-3)’ 
after  ‘18  generic 
software  categories. 

9 

sec  2.1,  para  1 

Insert  ‘system’  after 
‘These’  »n  2nd  sen¬ 
tence. 

10 

sec  2.1, para  3 

Add  ‘taken’  after 
‘approach’ in  3rd 
sentence. 

11 

sec  2.2.2. 1 

Amplify  meaning  of 
item  1. 

12 

sec  2.2.2.1 

Replace  ‘by  Space’ 
with  ‘of  Space’  in 
item  2. 

13 

sec  3.2 

Replace  example  of 
problem  with 
foreign  methodolo¬ 
gies  with  clause 
‘where  language 
and  time  barriers 
complicate....’ 

AT- 2 


14  sec  4.2  Make  changes  in 

text  so  inverse  pro¬ 
portions  are 
explained  as  direct 
proportions. 

15  sec  4.2,  item  8  Expand  and  clarify 

meaii'ng  of  correct¬ 
ness. 


16 

sec  4.4,  para  2 

Change  ‘chose’  to 
‘choose’  in  first  sen¬ 
tence. 

17 

sec  5,  para  2 

Change  ‘original 
proposal  design’  to 
‘design  originally 
proposed’. 

18 

sec  5,  para  6 

Insert  ‘Air  Force 
Mission’  in  front  of 
appendices  in  fiist 
sentence. 

19 

sec  6,  para  2 

Add  ‘of  the  guide¬ 
book’  after  ‘Appen¬ 
dix  C’. 

20 

sec  6,  para  2 

Second  sentence 
needs  a  verb. 

21 

sec  7.1,  para  3 

Add  some  text 

about  where  ratings 
come  from. 


Location 


Change/ Comment 


sec  7.1,  para  4 

Make  clear  that 
figures  7-3  &  7-4 
art  used  to  fill  in 
desired  column  of 
worksheet  and 
make  some  refer¬ 
ence  to  setting  up 
of  ideal  methodol¬ 
ogy. 

worksheet 

Change  ‘Score’  on 
second  sheet  to 
‘MS’. 

sec  7.1,  para  7 

Explain  that  third 
path  is  scored  by 
user. 

sec  7.1,  eqn 

Explain  that  MS 
stands  for  Metho¬ 
dology  Score. 

sec  7.1,  para  8 

Add  ‘nominally’ 
before  ‘desired’  in 
last  2  sentences. 

sec  7.1, para  8 

Put  in  rationale  for 
formulas  and  paths. 

sec  7.2,  para  2 

Put  in  pointer  to 
Appendix  B  on 
item  2. 

Appendix  A, 

Update  same  as 
guidebook  version 
is  updated. 
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